Re: [boost] GUI foundations

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-02 10:48:10

Andy Little wrote:
> "Reece Dunn" <msclrhd_at_[hidden]> wrote
>>Andy Little wrote:
>>>"Reece Dunn" <msclrhd_at_[hidden]> wrote
> 
>>>>I have, as well as many others, have made attempts into this brave new
>>>world
>>>>;).
> 
> I have been looking through your Boost.GUI library , (but only using VC7.1 ... I
> should delve into X...whatever)
> I am aware of the problem that windows applications  use winMain as a
> program-entry-point. However in VC7.1 it possible to change this in the Linker >
> advanced  > entry point box. If you use the entry point mainCRTStartup then main
> will be used as a program entry point. (Then you can change winMain to main in
> code. I'm not too sure about the way arguments are handled yet but it would be
> easy to preprocess these before main of course) This  solves one problem! I
> 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 :(
*  is there a simple way to do this without messing with the entry point 
in all the projects that use Boost.GUI?
*  you can override the entry point (like is done with the minimum CRT 
for ATL applications), but will this work with Boost.GUI + normal CRT?

> 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.

> 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 :)!

> 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.

> 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.

>>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 ));

>>I would also like the option of using native control/component types (or at
>>least in terms of L&F and usability) as well as a cross platform L&F that
>>Java can produce. Skinnable components at compile time (allowing a run-time
>>skin option).
> 
> custom L&F is obviously essential. Model-view-controller,Java AWT/ Swing and
> VFC( mentioned in docs but not read by me yet) are worth looking at regarding
> L&F.

Indeed.

> 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.

>>The Win32 API can use either wide character or narrow versions. Using the
>>narrow versions on WinNT and above can cause performance issues with the
>>narrow -> wide -> narrow string conversions done by the OS. Therefore, it
>>would be useful to have something like a gui::string that is std::string on
>>narrow character platforms (Win32 built with *A API variants, XWindows,
>>etc.) and std::wstring on wide character platforms (Win32 built with *W API
>>variants).
> 
> OK, but even in a word-processing application the amount of text on screen at a
> time cannot be that big. Is conversion speed that critical?

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.

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.

>>This also has an impact on platform Unicode support. The "native conversion"
>>I was referring to was that you cannot do:
>>
>>  std::wstring str( "foo" );
> 
> Yes thats a problem!  Ideally  think there should be a Unicode string rather
> than wstring (VFC, and Java have this!) , meanwhile basic_string<char> is fairly
> portable. Because there is no console output characteristics defined for wchar
> one could say that non cahracter output is actually part of the graphics module
> . The graphics module should be seen as a module with few dependencies so
> various modules acn be plugged in.

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 )).

>>at the moment. std::basic_string< native-character-type > should be the
>>string type of preference.
> 
> As you may guess by now I would want the ability to have the same semantics for
> a type for every platform defined.
> It is easy then for the user  to define native_character_type as a typedef.

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 :)

- Reece