Re: [boost] GUI library: vapourware?

From: Andy Little (andy_at_[hidden])
Date: 2005-09-30 04:42:54

"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> wrote in message
news:dhi15d$cj3$1_at_sea.gmane.org...
>
> "Andy Little" wrote:
>
>>> If anything you may join existing "modern C++"
>>> GUI library like John Torjo's win32gui,
>>
>> Is win32gui ever seriously going to target anything other than Windows?
>>
> AFAIK yes. John started preparations for GTK support though
> he "would welcome other's help".

(Sincerely to John Torjo -  I have only skimmed the surface in win32gui. I may
have a lot wrong.  There may be a lot I have missed.)

There is a lot of mention of  Windows stuff in the implementation. There is even
sdi_frame(CFrameWnd), mdi_frame(CMDIFrameWnd), WM_SIZE (et al) message etc.
(IIRC using FrameWnd it was difficult to try to make switchable views). Anyway,
in win32gui that I have looked at there is very little abstraction away from
Win32 API. For example in  win32gui/examples  program entry is:
    int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR lpCmdLine, int
nCmdShow)

AFAIK the common view on this list is not to subvert main. (VCF scores again It
uses main for GUI on Windows. Despite templates win32gui seems to use much of
the *patterns* in MFC like GDI , though even Microsoft has moved on with eg
GDI+. There are alternatives to DeviceContext approach too but are they explored
here?
IMO To make win32gui cross-platform will require a higher level of abstraction
than is there currently. For instance repeatedly the look and feel issue has
come up on this list. win32gui looks to be similar to Java.awt in that it is a
thin wrapper over the underlying API. However Java have now rejected that model
with Swing, which does much more low level work. It would be interesting to find
out why the java designers  felt they needed to change and made this choice.
Maybe it is even possible to have both ways

On the plus side win32gui has various units for length which is commendable! I
like that! In my experience units seriously do give device independence!

What I want of a C++ GUI :

1 The goal is a GUI as part of the C++ standard. Java has not one but 2. Moral -
Even if the first C++ standard GUI is not very good its worth doing for the
experience gained. So far in all the C++ GUI libraries cited I have not seen any
with this as a primary goal.
2 Platform independence. Obvious!  In practise means a philosophical abstraction
is required. A "top down" design. To facilitate this design and construction of
such a library should be carried out on several operating systems
simultaneously. ( Boost is good at that ! )
3 Reuse of  standard (and boost :-)  ) libraries even if there are some
problems. Seems obvious from here but GUI libraries cited seem to spend a lot of
effort to  roll their own. There may be a reason - thread safety? However even
if this is a problem it is worthwhile trying to use the standard library in
order to improve it.
4 The look and feel issue is major for potential users. It is important that the
GUI should have the capability to have the "look and feel" of an operating
system (Ideally Whether that is the one its working on or not)
5 Must use main as an entry point. Seems trivial but affects how lightweight a
GUI application is. Lightweight is good!

regards
Andy Little