RE: [boost] Re: GUI Library Proposal for a Proposal

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-11-05 07:34:58

Russell Hind wrote:
>Edward Diener wrote:
>>
>>No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go
>>there, or have anything to do with supporting any other GUI 
>>implementation.
>
>Also, wxWindows is a huge library.  If we were to introduce something in 
>boost, I'd very much like it to be as small and light weight (as win32gui 
>is supposed to be), not a collection of multi-megabyte dlls required, just 
>to wrap win32 or what ever the underlying library is.

I am in the process of writing a platform-independant GUI (available at: 
http://uk.geocities.com/msclrhd/gui/gui.zip) that aims to be small and 
lightweight. This code is stll in the early stages and currently targets 
Win32/64 with minimal Cocoa/PalmOS support.

>If people want more powerful components, they can be added afterwards, but 
>the underlying library around core OS controls should be as small as 
>possible.

In my library, I am working on:
*  gui::event_handler supporting lightweight "windowless" controls
*  gui::window supporting windows like the main frame, MDI child frames, 
etc.
*  gui::form (i.e. a frame with controls/layout set by an external designer 
referenced by ID) that includes dialog boxes in Win32. I do not have an 
implementation of gui::form yet.
*  gui::control supporting controls/widgets like buttons within a window or 
form

These 4 classes should then make it possible to derive your own classes to 
support edit controls, property sheets, MDI windows, etc. I do not 
explicitly implement any of these extra UI components because they are 
platform dependant and will add to the complexity of the framework. This is 
especially true for things like "splitter" windows and floating/docking 
toolbars.

Also, other components can be added at a later stage if necessary. As for 
the event processing mechanism, I have decided to use a std::map< event_id, 
void ( gui::event_handler::* )( gui::event * ) > that allows:

class main_frame: public gui::window
{
   public:
      void ev_destroy( gui::event * );
      void EvDraw( gui::event * );
      main_frame( gui::string name ): gui::window( ... )
      {
         set_handler( WM_DESTROY, &main_frame::ev_destroy );
         set_handler( WM_PAINT, &main_frame::EvDraw );
      }
};

At the moment, this does not support chaining of handlers (something on my 
todo list). The main event loop is controlled via gui::event_loop that does 
support filtering of events (e.g. processing keyboard shortcuts).

There are also platform-independant versions of position (NSPoint, POINT, 
etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that 
make use of properties allowing window positions to be handled in a 
platform-independant manner, e.g.:

void main_frame::resizing( gui::event * )
{
   area a = get_client_area();
   a.deflate( gui::size( 5, 5 ));
   pane -> move( a );
}

At the moment, you need to register Win32/64 window classes using:
   gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE 
);
but I am looking to abstract this.

I am all for getting a group of people together from the boost mailing list 
interested in GUI and developing a general GUI framework. It may be useful 
to have at least one person from the C++ standards committee to get input 
from the standards people.

Regards,
Reece

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/