Re: [boost] GUI foundations

From: Andy Little (andy_at_[hidden])
Date: 2005-10-02 09:42:53

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

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?

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;

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.

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)

[cut]

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

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

[cut]

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.

As far as compile time entities is concerned I think they could be very useful
e.g :

namespace gui{ namespace meta{ ?

 // colors defaut param for eg num valid bits
  typedef rgb_color_c<int,255,0,0> red;

// taken from SVG
struct in;
struct mm;
struct cm;
struct px;
struct pt;
struct pc;

// or vect ;-)
template<typename  X, typename Y, typename Units>
struct point;

template <typename TLpoint, typename BRpoint, typename Units>
struct rect;

// resource handles:

template < typename ResourceTag,typename ResourceInfo>
struct handle;

typedef handle<menu,MyMenu> my_menu;

}} //gui::mpl

Might even be possible to use this for  resource scripts...

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

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

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

regards
Andy Little