A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework: [1] Support constructor-based window creation, e.g.: frame.add( new gui::button( "Boost!" )); The justification for this is that I find using an OnCreate + Create style for creating windows (MFC and WTL) or similar is too complex: the above method for creating a component is 1 line compared to many lines in other frameworks. For the record, I have a basic version of the above implemented in Windows where the add function changes the parent of the child component. This would make it easy to implement advanced GUI like docking controls. [2] Support for lightweight components: components that do not use native window handles. This will allow for advanced facilities like layout managers. The infrastructure should be such that using native and lightweight components is transparent. Component positioning should be allowed to be set explicitly (absolute position - using the units library?) or set using layout managers. There should be wrapping, clipping and stretching position schemes for the various layout managers. [3] The event manager should be platform independent, flexible and extensible. That is to say, if you are using Windows, you should be able to register a handler for a Windows-specific message. In general, the library should match system messages to an independent version wherever possible. It should also support message reflection where a message for a component is handled by a different window or object (e.g. responding to a close message on an application object). When an event is handled, the handler should inform the manager how to process the event: (1) the event has been handled (e.g. focus events); (2) the event was not handled - try the next handler; (3) the event was handled, but processing should continue (e.g. draw events) There has been discussions in earlier threads (Java style GUI in C++) about using boost::signal as an event handler. I have two questions regarding this: (1) if I have n message types, do I need n boost::signal objects? If so, this would increase the size of each component. Also, what if you want a "handle all events" handler. (2) if generic events are defined in an 'event' object, and a handler function has the form: event_handled_type eventfn( const event & e ); what if you want to support: event_handled_type pressed( const mouse_event & me ); event_handled_type key_down( const key_event & ke ); Regards, Reece
Reece Dunn <msclrhd@hotmail.com> writes:
A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" ));
Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Reece Dunn <msclrhd@hotmail.com> writes:
A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" ));
Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources.
Indeed. You can do this: frame->add<gui::button>( "Boost!"); Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
David Abrahams wrote:
Reece Dunn <msclrhd@hotmail.com> writes:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" ));
Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources.
Hmm, do you know of a C++ GUI framework that gets this right? Just curious Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
David Abrahams wrote:
Reece Dunn <msclrhd@hotmail.com> writes:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" ));
Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources.
Hmm, do you know of a C++ GUI framework that gets this right?
Just curious
There is also the issue of dynamically creating the GUI. If you create a docking/floating toolbar for example, which object stores the toolbar? The docked frame or the floating frame? Also, what if you have a large number of GUI components? Storing them in the frame class would just increase the size of the object to the point where it is unusable. Also, doing: frame.add( gui::button( "Boost!" )); frame.add( gui::textbox( "Hello", 25, true )); would incur copy penalties. What if you want to share the same object across multiple objects (e.g. the docking/floating frame) instead of making a separate copy of it. One solution would be to make gui::frame, gui::boost, etc. lightweight wrappers around the actual objects. They would use the PIMPL paradigm to store the actual object. That way, these can be easily passed around, managing the allocated resource themselves, as well as providing the mechanism to select native/lightweight components. Regards, Reece
There is also the issue of dynamically creating the GUI. If you create a docking/floating toolbar for example, which object stores the toolbar? The docked frame or the floating frame?
Fow win32gui, I don't worry about this. Anyway, the OS has to have some sort of "parent" property and ways to enumerate the windows. (of course, I might be wrong - I'm only very familiar with Widows OS). Thus, internally I have a map: from HWND handle to a pointer to a window. Whenever, I need something like, the parent(), I find a HWND handle to the parent, and then look it up in my map. Then, simply return it. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
Also, what if you have a large number of GUI components? Storing them in the frame class would just increase the size of the object to the point where it is unusable.
Also, doing:
frame.add( gui::button( "Boost!" )); frame.add( gui::textbox( "Hello", 25, true ));
What you could do is: frame->add<gui::button>("Boost!"); frame->add<gui::textbox>("hello", 25, true); Internally, they will map to new gui::button("boost") and new gui::textbox( "hello", 25, true) Thus, there will NO copying whatsoever. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
John Torjo <john.lists@torjo.com> writes:
Also, what if you have a large number of GUI components? Storing them in the frame class would just increase the size of the object to the point where it is unusable. Also, doing: frame.add( gui::button( "Boost!" )); frame.add( gui::textbox( "Hello", 25, true ));
What you could do is:
frame->add<gui::button>("Boost!"); frame->add<gui::textbox>("hello", 25, true);
Internally, they will map to new gui::button("boost") and new gui::textbox( "hello", 25, true)
Thus, there will NO copying whatsoever.
Or you could just build pimpl gui objects with shared reference semantics so people could copy them about naturally. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
What you could do is:
frame->add<gui::button>("Boost!"); frame->add<gui::textbox>("hello", 25, true);
Internally, they will map to new gui::button("boost") and new gui::textbox( "hello", 25, true)
Thus, there will NO copying whatsoever.
Or you could just build pimpl gui objects with shared reference semantics so people could copy them about naturally.
Sorry - I must be expressing myself pretty badly ;) What you just said - that's exactly what I meant. By "No copying whatsoevet" - I meant internally. Or in other words, a window class is not required to have copy-semantics. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
Thomas Witt <witt@acm.org> writes:
David Abrahams wrote:
Reece Dunn <msclrhd@hotmail.com> writes:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" )); Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources.
Hmm, do you know of a C++ GUI framework that gets this right?
Haven't been paying much attention recently, so, no I don't. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Thomas Witt wrote:
David Abrahams wrote:
Reece Dunn <msclrhd@hotmail.com> writes:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" ));
Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources.
Hmm, do you know of a C++ GUI framework that gets this right?
I guess mine ;) But it's Windows-only. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
On Fri, Sep 24, 2004 at 07:21:10AM -0700, Thomas Witt wrote:
David Abrahams wrote:
Reece Dunn <msclrhd@hotmail.com> writes:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" ));
Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources.
Hmm, do you know of a C++ GUI framework that gets this right?
Just curious
gtkmm [1] doesn't get rid of new completely, but it does provide automatic widget management that pretty clean. I think their argument is that fully managing widgets would make the use of stack based widgets too cumbersome/impossible. I think their approach is very flexible and easy to use. [1] http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch18.html -- CJ van den Berg <cj@vdbonline.com>
Reece Dunn wrote:
There has been discussions in earlier threads (Java style GUI in C++) about using boost::signal as an event handler. I have two questions regarding this: (1) if I have n message types, do I need n boost::signal objects?
Define message types ? Boost signal works off of signals defining a particular member signature for a slot to handle the signal.
If so, this would increase the size of each component.
You can have base class components handle certain signals and derived class components only handle signals which base class components do not handle. This is no different than any other OOP framework with virtual functions.
Also, what if you want a "handle all events" handler.
What's you parameters for handling any event. Unless they are void *, or better yet boost::any or boost::variant, with extra info to define the particular event, you will be hard put to handle all events with a single handler. Somehow the handler must know what event it is handling when it does so.
(2) if generic events are defined in an 'event' object, and a handler function has the form:
event_handled_type eventfn( const event & e );
what if you want to support:
event_handled_type pressed( const mouse_event & me ); event_handled_type key_down( const key_event & ke );
What are you trying to do here ? I would assume that mouse_event and key_event are derived from event.
Reece Dunn wrote:
A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework:
[1] Support constructor-based window creation, e.g.:
frame.add( new gui::button( "Boost!" ));
did you mean frame->add(..)? I really think that every window object should have - behind the scenes - a shared pointer. One reason for this is: // I assume you want another pointer to the window, // not another on-the-screen window. frame a = b;
The justification for this is that I find using an OnCreate + Create style for creating windows (MFC and WTL) or similar is too complex: the
indeed so ;)
There has been discussions in earlier threads (Java style GUI in C++) about using boost::signal as an event handler. I have two questions regarding this: (1) if I have n message types, do I need n boost::signal objects? If so, this would increase the size of each component. Also, what if you want a "handle all events" handler. (2) if generic events are defined in an 'event' object, and a handler function has the form:
event_handled_type eventfn( const event & e );
what if you want to support:
event_handled_type pressed( const mouse_event & me ); event_handled_type key_down( const key_event & ke );
In my view, I assume this is possible. All you need is a constructor for mouse_event that takes an event param. Something like: mouse_event::mouse_event(const event & e) { // interpret the event as a mouse event } Same goes for key_event. In fact, Dec 04 issue of CUJ should be dealing with this issue ;) Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
participants (6)
-
CJ van den Berg -
David Abrahams -
Edward Diener -
John Torjo -
Reece Dunn -
Thomas Witt