Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk