From: Andy Little (andy_at_[hidden])
Date: 2005-09-30 04:42:54
"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> wrote in message
> "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
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
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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk