Re: [boost] GUI foundations

From: Andy Little (andy_at_[hidden])
Date: 2005-10-02 13:32:57

"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
news:dhove2$jj9$1_at_sea.gmane.org...
> Andy Little wrote:
>> "Reece Dunn" <msclrhd_at_[hidden]> wrote
>>>Andy Little wrote:
>>>>"Reece Dunn" <msclrhd_at_[hidden]> wrote

>> discovered this while reading the VFC documentation. It works fine.
>
> I am aware of this, but was wondering several things:
> *  main() will create a console window as well as the GUI window :(

If you use the linker flag /SUBSYSTEM:WINDOWS instead of /SUBSYSTEM:console ,
it doesnt put up a console window.

FWIW with these settings args in:

    int main(int argc,char* argv[])

are valid :-)

[cut]

FWIW Heres my linker settings

/OUT:"Debug/ReeceGui.exe" /INCREMENTAL /NOLOGO
/LIBPATH:"XXX\boost_1_33_0\bin\boost\libs\signals\build\libboost_signals.lib\vc-7_1\debug\runtime-link-static"
/DEBUG /PDB:"Debug/ReeceGui.pdb" /SUBSYSTEM:WINDOWS /ENTRY:"mainCRTStartup"
/MACHINE:X86   kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

[cut]

>> FWIW I am thinking of working on your Boost.Gui. One essential  difference I
>> would like to make is to try to use the same types on each platform, so for
>> example window sizes would all be in either integers or floats. Ideally they
>> should be templated on each type. What do you thinlk?
>
> Feel free to modify it as you want :) I have been very busy with work
> and other things, and working on Boost.GUI isn't a high priority for me
> at the moment.

Shame  I dont think I'll get much done in the near future either:-(  .. What I
really need is to get it running on Linux/Unix and Mac I
guess...

>> I might go further  and add units (maybe defaulting to pixels)
>>
>> typedef gui::rect<px,int> rect 1;
>> typedef gui::rect<pc,double> rect 2;
>> typedef gui:rect<mm,int> rect 3;
>
> That looks great :)!

I'd better get own with it then... ;-)

>> IMO from experience  this is very powerful and makes coding much easier.
>>
>> Alternatively / as well it might be good to set the transform ( units and
>> ,Wheres (0,0), is +Y up or down, etc ) per window.
>
> Interesting. You could have a windows transform and a mac transform,
> aliasing that to OS transform.

Thats it!  so it defaults to the same settings on each platform. Up is always up
etc.. and you can set a Text (y goes down etc) or Graphics mode.

>> BTW On the issue of size and point ; The problem with operations specified is
>> that assuming:
>>    point p1,p2,p3
>> operations such as:
>>    point result_point = (p1 +p2 +p3)/3;
>> are legal mathematical constructs ( whereas (p1+p2)/3 isnt of course). Thats
>> why
>> Id prefer to go with an entity called vect which stands in for both  size and
>> point. (You could make point safe  with some runtime overhead I guess)
>
> I would prefer vector over an abbreviation.

hmm .. Ok, I guess users  can change it if they wish. Anyway you seem to
approve in principle ?
I  currently use a namespace called two_d  e.g two_d::vector<..> .

>>>I agree that the library should be designed on the abstract level, but it
>>>should also be possible to pass a rectangle object to GetClientRect (or the
>>>equivalent in Mac, PalmOS, etc.) without having to write a lot of
>>>platform-dependant code yourself.
>>
>> Ok but because you will inevitably be using the platform specific API , this
>> will usually be easy to achieve.
>>
>>>That is, I want it to be easy to interact with Win32, XWindows or Mac code
>>>/in a way that is simple for the user/.
>>
>> Maybe as a plugin.?
>
> What I don't want to do is:
>
>    gui::vector pt;
>    NSPoint ptNative;
>    CallSomePointFunction( &ptNative );
>    pt = convert_vector( ptNative );
>
> but:
>
>    gui::vector pt;
>    CallSomePointFunction( pt.native());
>
> I suppose I could write my own extension to allow:
>
>    gui::vector pt;
>    CallSomePointFunction( native_point( pt ));

Ok.. I guess the idea is that it should work with existing code?(See below about
incorporating it into C++ standard)

[cut]

>> As far as compile time entities is concerned I think they could be very
>> useful
>>  [snip]
>> Might even be possible to use this for  resource scripts...
>
> These look great.

Thanks!

[cut]

> I am willing to bet that most commercial applications that target WinNT
> and above are built using the Unicode versions of the API. Saying that
> they must use the ansi variants instead would make some, if not most, of
> the companies reluctant to switch to Boost.GUI or the standard C++ GUI.

I'm looking in terms of overtaking the competition...erhh ..hmm gradually ;-)
My first target  audience for this would be C++ newcomers.

> Also, applications that interact with COM will send and receive BSTR
> strings that are always wide. These applications will most likely be
> built in Unicode to allow the BSTR strings to be passed to the Win32 API
> without conversions.

Ok... but is this actually  the GUIs responsibility? Cant system calls  be used
without a GUI .?
(Ok They are generally bundled in). However  the standard doesnt  understand the
concept of interprocess communication( or does it?) . If possible I would like
to keep the thing as lightweight as possible The goal is a minmal GUI that can
be incorporated in the standard for "basic GUI functionality".   Providing a
rigorous specification for even that would be a huge amount of work. I guess
this is why  I'm not  getting too worried about os specifics except to hide
them.. I think  they would be 'implementation defined" in the standard.

[cut]

> Having the string rendering as part of the graphics module is
> interesting (indeed, the Windows GDI and I assume XWindows et. al. have
> this as part of the graphics sub-system). There should be the concept of
> a font. At least it should specify font face (e.g. "Courier New") and
> size (e.g. font_size< pt >( 12 )).

Yes. There are a large range of fonts about  to take inspiration from!
Anyway this would be  part of the graphics  sub-system (Though default font is
bound up with L&F of course).

[cut]

> Or an easier option would be to use templates like are dome with the
> string types:
>
> template< typename CharT >
> struct basic_window
> {
>    void set_title( const std::basic_string< CharT > & title );
> };
>
> Thus, you won't need to use a specific string representation and you get
> the same semantics on every platform defined that you like :)

Thats sounds good. Thats whad I like !

regards
Andy Little