"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:dhi15d$cj3$1@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