Hi All, We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required. There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc. Each of these layers is conceptually independant, but builds on top of the other. Should there be a separate library for each of these layers (Boost.Platform, Boost.Geometry, Boost.Graphics, Boost.Events and Boost.UIObject)? The design for the UI object layer must be able to support: * native-based UI objects that are dynamically constructed. * native-based UI objects taken from pre-built elements, e.g. objects on a form. * lightweight UI objects that are not native-based. * custom drawn native-based UI objects (either dynamically constructed or from pre-constructed objects), in essence a hybrid of native-based and lightweight UI objects. All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as: ui::object ui::frame ui::form ui::main_frame ui::popup ... ui::widget ui::textfield ui::textarea ui::button ui::grid ui::table ... ui::layout_manager ui::flow_layout ... Here, I want to keep the UI object heirarchy as simple as possible. That is, the heirarchy is not dependant on platform specifics, but the UI object group to which the object belongs. A UI object consists of event processing and sizing/positioning. A frame is a UI object that has border (frame) decoration, with a main frame being a top-level frame, a form being a frame that is defined by an external resource and a popup is a frame that hosts components (e.g. a list of menu items for a specific menu item). A widget is a UI object that has specific events and data associated with it. A layout manager is a lightweight UI object that aids the positioning of widgets. The question is how to make it easy to specify both lightweight and native UI objects. Using a component< render_as< Renderer > > structure does not allow for an easy implementation -- how do you map the implementation details for a specific component and how do you make it extensible? I do not yet see an easy approach. I am thinking of a PIMPL-style implementation, but using templates to simplify allocation does not allow for easy construction of UI objects. Consider: ui::button ok( "OK", ui::button::push ); ui::button_impl< ui::lightweight_button > cancel( "Cancel" ); Likewise, having a constructor that takes an implementation, how do we construct the generic interface that allows this implementation. Consider: ui::button cancel( "Cancel", new ui::lightweight_button()); Also, having a shallow interface (i.e. each UI object is a top-level object), you would need duplicate code to handle common things like event handling and move/resize operations. All of these approaches has their own advantages and disadvantages. Regards, Reece
* Reece Dunn <msclrhd@hotmail.com> [2004-12-29 14:39]:
All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as:
ui::object ui::frame ui::form ui::main_frame ui::popup ... ui::widget ui::textfield ui::textarea ui::button ui::grid ui::table ... ui::layout_manager ui::flow_layout ...
Here, I want to keep the UI object heirarchy as simple as possible. That is, the heirarchy is not dependant on platform specifics, but the UI object group to which the object belongs.
I'd steer clear of an object heirarchy. The requirements you put forward indicate that a hierarchy is the wrong abstaction. I don't see why a main_frame has to be a decendant of the same root object as a layout_manager. -- Alan Gutierrez - alan@engrm.com
Alan Gutierrez wrote:
* Reece Dunn <msclrhd@hotmail.com> [2004-12-29 14:39]:
All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as:
ui::object ui::frame ui::form ui::main_frame ui::popup ... ui::widget ui::textfield ui::textarea ui::button ui::grid ui::table ... ui::layout_manager ui::flow_layout ...
Here, I want to keep the UI object heirarchy as simple as possible. That is, the heirarchy is not dependant on platform specifics, but the UI object group to which the object belongs.
I'd steer clear of an object heirarchy. The requirements you put forward indicate that a hierarchy is the wrong abstaction. I don't see why a main_frame has to be a decendant of the same root object as a layout_manager.
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Alan Gutierrez wrote:
* Reece Dunn <msclrhd@hotmail.com> [2004-12-29 14:39]:
All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as:
ui::object ui::frame ui::widget ui::layout_manager
Here, I want to keep the UI object heirarchy as simple as possible. That is, the heirarchy is not dependant on platform specifics, but the UI object group to which the object belongs.
I'd steer clear of an object heirarchy. The requirements you put forward indicate that a hierarchy is the wrong abstaction. I don't see why a main_frame has to be a decendant of the same root object as a layout_manager.
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object. The heirarchy above is for a UI object, where a UI object has moving/positioning and event handling integral to it. Consider: class mainfrm: public ui::main_frame { ui::flow_layout buttons; ui::table data_view; public: void update_layout( const geom::rect & area ) { geom::size bs = buttons.get_minimum_size(); geom::size ds = data_view.get_minimum_size(); bs.move( ... ); ds.move( ... ); } }; void gui_main() { mainfrm app( "Demo" ); app.move( 100, 100, 300, 500 ); } How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base? Here, I was using the namespace as part of the name to denote the role that the class plays, not that it is a monolithic uberclass. Note that I haven't suggested having ev::event_loop, geom::metric, geom::point, graphics::device, graphics::font, graphics::canvas, etc. sharing a common base class because they do not fit into what constitutes a *UI object*. Perhapse the high-level vector graphics objects (vector::line, vector::ellipse, etc.) will, but that is only a consideration. Regards, Reece
On Thu, 30 Dec 2004 08:25:51 +0000 Reece Dunn <msclrhd@hotmail.com> wrote:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base?
No one should confuse me with a GUI expert, so take what I say with a grain of salt w.r.t. GUI development. However, I want to respond to this question, as it really does not have anything to do with GUIs. I assume you are talking about having a common base class with virtual functions for common tasks. This is certainly one way of doing it, and not being a GUI person, I can not comment on the "correctness" of such a proposal - it may well be the best methodology. However, to answer your question, you can certainly accomplish the same thing (i.e., "write UI objects that can interact with each other") without a common inheritance hierarchy. What kinds of interaction between the objects requires inheriting from a common base class, as opposed to using Boost.Bind, Boost.Function, and Boost.Signal?
Jody Hagins wrote:
I assume you are talking about having a common base class with virtual functions for common tasks. This is certainly one way of doing it, and not being a GUI person, I can not comment on the "correctness" of such a proposal - it may well be the best methodology.
Pet peeve... you meant "method" not "methodology" ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
* Jody Hagins <jody-boost-011304@atdesk.com> [2004-12-30 10:24]:
On Thu, 30 Dec 2004 08:25:51 +0000 Reece Dunn <msclrhd@hotmail.com> wrote:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base?
No one should confuse me with a GUI expert, so take what I say with a grain of salt w.r.t. GUI development. However, I want to respond to this question, as it really does not have anything to do with GUIs.
I assume you are talking about having a common base class with virtual functions for common tasks. This is certainly one way of doing it, and not being a GUI person, I can not comment on the "correctness" of such a proposal - it may well be the best methodology.
However, to answer your question, you can certainly accomplish the same thing (i.e., "write UI objects that can interact with each other") without a common inheritance hierarchy.
What kinds of interaction between the objects requires inheriting from a common base class, as opposed to using Boost.Bind, Boost.Function, and Boost.Signal?
This a good question. It needs be be asked. Following a nested shape model is classic, might well be correct, but should not go unquestioned. This is a new library that has at its disposal new techniques, like generics. This is the old schoool: If I have a raido button control I can use Composition to draw in on by nesting it it a tree of objects. ui::window \-> ui::frame \-> ui:splitter \-> ui::border_layout \-> ui::flow_layout \-> ui::radio_button \-> ui::glyph \-> ui::label An inheritence heirarchy can be something like. ui::object \-> ui::widget \-> ui::button \-> ui::label New school: Divide the ui up into rendering strategies. Provide a well-defined transition between strategies. A flash animation on a web page requires far more in the way of hit/visibility testing, rendering, than the web page. Do I want a heavy weight ui::object to represent every object of vector graphics rendering? Are not a lot of those shapes really calculated shapes and not actual objects in memory? Does the nested ui::object make senese for all rendering? Does it scale? No. If the radio button is one of one million radio buttons for a database result set do I have a sparse matrix with a million radio buttons? Do I employ a flyweight pattern so that I can pretend that there are a million radio buttons on the drawing surface? Or do I want to have a model for rendering that more accurately depicts a grid? Yes. Once, I've left the nesting of the frame, and entered into the grid, I abandon the nested object model altogether, in favor of sparse data structures. I think the model is so. ui::renderer< ui::surface< ui::surface_traits > , ... ??? > ui::grid< ui::surface<ui::surface_traits>, ??? ... > ui::form< ui::surface<ui::surface_traits>, ??? ... > ui::document< ui::surface<ui::surface_traits>, ??? ... > ui::canvas< ui::surface<ui::surface_traits>, ??? ... > Each of the above renderes can have opmtimal strategies, different paradigms entirely, for event rounting, hit and visibility testing, and rendering. Events can bubble up through the blocks of a document, or then can go directly to a cell on a grid. For a ui::form, nesting an object heirarchy to a common root object, is fine. In fact, what is proposed can be one renderer implementation. ui::nested_component< ui::radio_button, ui::bounding_traits, ui::event_set, ??? > For a grid I might have a different render participation strategy for the component. ui::etheral_component< ui::radio_button, ui::bounding_traits, ui::event_set, ??? > A window frame is easily described as a set of nested objects, as is a typical form o' widgets. That happy conincidence binds most UI libraries to this ui::object rooted model. Care has to be through about how messages cross the boundries between rendering strategies, but imposing nested objects on all strategies makes grids and documents cumbersome. -- Alan Gutierrez - alan@engrm.com
Jody Hagins wrote:
On Thu, 30 Dec 2004 08:25:51 +0000 Reece Dunn <msclrhd@hotmail.com> wrote:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base?
No one should confuse me with a GUI expert, so take what I say with a grain of salt w.r.t. GUI development. However, I want to respond to this question, as it really does not have anything to do with GUIs.
I assume you are talking about having a common base class with virtual functions for common tasks. This is certainly one way of doing it, and not being a GUI person, I can not comment on the "correctness" of such a proposal - it may well be the best methodology.
However, to answer your question, you can certainly accomplish the same thing (i.e., "write UI objects that can interact with each other") without a common inheritance hierarchy.
What kinds of interaction between the objects requires inheriting from a common base class, as opposed to using Boost.Bind, Boost.Function, and Boost.Signal?
Take a layout manager, for example. A layout manager hosts a series of UI objects (these may themselves be layout managers). The layout manager requests the size of the object and moves an object to the new position. This behaviour needs to be common between the UI objects in order to allow the generic calculations. I am not sure what the best approach is and am working on revising the implementation I have to accommodate lightweight objects. My focus is towards native objects, whereas Alan is focused on lightweight objects. Using a template along the lines of: ui::object< ui::native, ui::button > btn( ... ); how do you create the object at the constructor, i.e. not using the Create/OnCreate structure of Win32/MFC/WTL. As for on-demand creation, this is dependant on the data model being used. For example, the grid UI object uses a cell_provider: struct cell_provider { virtual std::string get_data( long r, long c ) const = 0; virtual bool is_editable( long r, long c ) const { return false; } virtual ui::object * get_object( long r, long c ) const { return 0; } }; where, if get_object( r, c ) returns 0, the cell is a text cell with the value get_data( r, c ), otherwise it is rendered using the UI object returned. Here, a text edit control is only needed when the cell is editable and the user interaction signifies an edit action. The grid or table control will maintain the visible cells and dispose of the cell data/object once the cell goes out of visibility. Here is another example of using a common base - how would you do this if they were separate? Granted for a table, you could have a tuple or for a grid you could restrict it to be a single UI object type (textfield, radio button, etc), but this complicates matters. BTW, I make use of Boost.Signal and Boost.Bind for event handling as these are necessary for the flexibility that they provide. Regards, Reece
* Reece Dunn <msclrhd@hotmail.com> [2004-12-30 12:39]:
Jody Hagins wrote:
On Thu, 30 Dec 2004 08:25:51 +0000 Reece Dunn <msclrhd@hotmail.com> wrote:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base?
No one should confuse me with a GUI expert, so take what I say with a grain of salt w.r.t. GUI development. However, I want to respond to this question, as it really does not have anything to do with GUIs.
I assume you are talking about having a common base class with virtual functions for common tasks. This is certainly one way of doing it, and not being a GUI person, I can not comment on the "correctness" of such a proposal - it may well be the best methodology.
However, to answer your question, you can certainly accomplish the same thing (i.e., "write UI objects that can interact with each other") without a common inheritance hierarchy.
What kinds of interaction between the objects requires inheriting from a common base class, as opposed to using Boost.Bind, Boost.Function, and Boost.Signal?
Take a layout manager, for example. A layout manager hosts a series of UI objects (these may themselves be layout managers). The layout manager requests the size of the object and moves an object to the new position. This behaviour needs to be common between the UI objects in order to allow the generic calculations.
I am not sure what the best approach is and am working on revising the implementation I have to accommodate lightweight objects. My focus is towards native objects, whereas Alan is focused on lightweight objects.
No. I'm interested in developing an event UI library that will work with Palm OS, and OS X, and I'd use native controls on both. This native versus light-weight cunumdrum is a Windows problem. They choose to implement their form controls using the same object heirarchy as their window controls. Everything is a window. This heirarchy proposes to do the same thing as Win32 GDI, whether the controls "wrap native" or are "light-wieght". A nested object heirarchy is one a handful of ways to manage a UI surface, and I don't believe it should be the foundation. I believe other stratgies should be treated as peers. -- Alan Gutierrez - alan@engrm.com
On the subject of GUI object hierarchies, I wanted to bring to everyone's attention the Boost Interfaces Library (BIL) currently being developed by Jonathan Turkanis which could be an excellent tool for building a flexible and efficient GUI library. There is a brief introduction to the library on the Boost wiki ( http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Interfa... ) The BIL library, provides a mechanism for non-intrusive structural subtyping. In other words any object can be used polymorphically if it provides function signatures which match those of the interface type. The advantages are that it eliminates the overhead of virtual tables in the objects. Also dynamic function dispatch only occurs when it is needed (i.e. through an interface reference). Most importantly the BIL removes the requirement of inheritance for polymorphism. The code for declaring the interfaces would look like this: BOOST_IDL_BEGIN(ILabel) BOOST_IDL_CONST_FN0(GetText, string) BOOST_IDL_CONST_FN0(GetAlignment, align_T) BOOST_IDL_END(ILabel) BOOST_IDL_BEGIN(IStandardButton) BOOST_IDL_FN0(GetLabel, ILabel) BOOST_IDL_FN0(GetDims, dim_struct) BOOST_IDL_END(IStandardButton) Using the interfaces would be done by simply declaring classes which implement the interfaces implicitly as below: class CenteredLabel { public: CenteredLabel(string s) : text(s) { }; string GetText() { return text; } string GetAlignment() { retun enumAlignHCenterVCenter; } private: string text; } class StandardOkButton { public: OkButton() : label("OK") { } dim_struct GetDims() { return dim_struct(100,50); } ILabel GetLabel() { return label; } private: CenteredLabel label; } Is the value of such as approach apparent or are more detailed examples warrranted? Christopher Diggins http://www.cdiggins.com
* christopher diggins <cdiggins@videotron.ca> [2004-12-30 16:17]:
The BIL library, provides a mechanism for non-intrusive structural subtyping. In other words any object can be used polymorphically if it provides function signatures which match those of the interface type. The advantages are that it eliminates the overhead of virtual tables in the objects. Also dynamic function dispatch only occurs when it is needed (i.e. through an interface reference). Most importantly the BIL removes the requirement of inheritance for polymorphism.
Is the value of such as approach apparent or are more detailed examples warrranted?
Crystal clear. Very cool. Thank you. -- Alan Gutierrez - alan@engrm.com
christopher diggins wrote:
On the subject of GUI object hierarchies, I wanted to bring to everyone's attention the Boost Interfaces Library (BIL) currently being developed by Jonathan Turkanis which could be an excellent tool for building a flexible and efficient GUI library. There is a brief introduction to the library on the Boost wiki ( http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Interfa... )
The code for declaring the interfaces would look like this:
BOOST_IDL_BEGIN(ILabel) BOOST_IDL_CONST_FN0(GetText, string) BOOST_IDL_CONST_FN0(GetAlignment, align_T) BOOST_IDL_END(ILabel)
What I am trying to get working is: 15: BOOST_IDL_BEGIN(IUIObject) 16: BOOST_IDL_FN4(move, void, g::metric, g::metric, g::metric, g::metric) 17: BOOST_IDL_FN2(move, void, g::metric, g::metric) 18: inline void move( g::point p ) 19: { 20: move( p.x, p.y ); 21: } 22: BOOST_IDL_END(IUIObject) with the latest CVS of Boost, but with msvc-8.0, I get: phase1.cpp(16): error C2061: syntax error : identifier 'BOOST_PP_TUPLE_ELEM_2_0' phase1.cpp(16): see reference to class template instantiation 'IUIObject_interface_impl_::generator_impl<Derived_,Flags_,Base_>::tracker_<boost::mpl::int_<N>,Dummy_>::type::interface_functions<XXX_>' being compiled with [ N=1 ] Any suggestions? Is there a version of the BIL that works with the CVS version (or 1.33) of Boost? And is the above valid, since this is the kind of thing I want? Regards, Reece
----- Original Message ----- From: "Reece Dunn" <msclrhd@hotmail.com> To: <boost@lists.boost.org> Sent: Friday, December 31, 2004 4:26 AM Subject: [boost] Re: Object Hierarchies using Interface Types with the BIL
christopher diggins wrote:
On the subject of GUI object hierarchies, I wanted to bring to everyone's attention the Boost Interfaces Library (BIL) currently being developed by Jonathan Turkanis which could be an excellent tool for building a flexible and efficient GUI library. There is a brief introduction to the library on the Boost wiki ( http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Interfa... )
The code for declaring the interfaces would look like this:
BOOST_IDL_BEGIN(ILabel) BOOST_IDL_CONST_FN0(GetText, string) BOOST_IDL_CONST_FN0(GetAlignment, align_T) BOOST_IDL_END(ILabel)
What I am trying to get working is:
15: BOOST_IDL_BEGIN(IUIObject) 16: BOOST_IDL_FN4(move, void, g::metric, g::metric, g::metric, g::metric) 17: BOOST_IDL_FN2(move, void, g::metric, g::metric) 18: inline void move( g::point p ) 19: { 20: move( p.x, p.y ); 21: } 22: BOOST_IDL_END(IUIObject)
with the latest CVS of Boost, but with msvc-8.0, I get:
Any suggestions? Is there a version of the BIL that works with the CVS version (or 1.33) of Boost? And is the above valid, since this is the kind of thing I want?
The obvious problem with your code is that the BIL interface is not intended to have any function implementation inside of it. It is in this sense more like a Java interface or a pure abstract base class. So if you want a move functions, I suggest moving them out in a separate class (which I call an extension) template<typename T> struct IUIObjectWrapper : public T { IUIObjectWrapper() : T() { } inline void move(g::point p) { T::move(p.x, p.y); } } typedef IUIObjectWrapper<IUIObject> IUIObjectExtension; This approach actually corrects what I percieve to be a huge flaw with many object libraries, which is the coupling of core functionality and derivable functionality. Also note that a new version of the BIL library is due out in a few days. Christopher Diggins http://www.cdiggins.com http://www.heron-language.com
Hi, So the boost interface library implements something like the gnu gcc signatures? You create proxy classes that forward to non-virtual methods? Regards Andreas Pokorny On Fri, Dec 31, 2004 at 11:09:14AM -0500, christopher diggins <cdiggins@videotron.ca> wrote:
----- Original Message ----- From: "Reece Dunn" <msclrhd@hotmail.com> To: <boost@lists.boost.org> Sent: Friday, December 31, 2004 4:26 AM Subject: [boost] Re: Object Hierarchies using Interface Types with the BIL
christopher diggins wrote:
On the subject of GUI object hierarchies, I wanted to bring to everyone's attention the Boost Interfaces Library (BIL) currently being developed by Jonathan Turkanis which could be an excellent tool for building a flexible and efficient GUI library. There is a brief introduction to the library on the Boost wiki ( http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Interfa... )
The code for declaring the interfaces would look like this:
BOOST_IDL_BEGIN(ILabel) BOOST_IDL_CONST_FN0(GetText, string) BOOST_IDL_CONST_FN0(GetAlignment, align_T) BOOST_IDL_END(ILabel)
What I am trying to get working is:
15: BOOST_IDL_BEGIN(IUIObject) 16: BOOST_IDL_FN4(move, void, g::metric, g::metric, g::metric, g::metric) 17: BOOST_IDL_FN2(move, void, g::metric, g::metric) 18: inline void move( g::point p ) 19: { 20: move( p.x, p.y ); 21: } 22: BOOST_IDL_END(IUIObject)
with the latest CVS of Boost, but with msvc-8.0, I get:
Any suggestions? Is there a version of the BIL that works with the CVS version (or 1.33) of Boost? And is the above valid, since this is the kind of thing I want?
The obvious problem with your code is that the BIL interface is not intended to have any function implementation inside of it. It is in this sense more like a Java interface or a pure abstract base class. So if you want a move functions, I suggest moving them out in a separate class (which I call an extension)
template<typename T> struct IUIObjectWrapper : public T { IUIObjectWrapper() : T() { } inline void move(g::point p) { T::move(p.x, p.y); } }
typedef IUIObjectWrapper<IUIObject> IUIObjectExtension;
This approach actually corrects what I percieve to be a huge flaw with many object libraries, which is the coupling of core functionality and derivable functionality.
Also note that a new version of the BIL library is due out in a few days.
Christopher Diggins http://www.cdiggins.com http://www.heron-language.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
----- Original Message ----- From: "Andreas Pokorny" <andreas.pokorny@gmx.de> To: <boost@lists.boost.org> Sent: Saturday, January 01, 2005 11:22 AM Subject: Re: [boost] Re: Object Hierarchies using Interface Types with the BIL
Hi, So the boost interface library implements something like the gnu gcc signatures? You create proxy classes that forward to non-virtual methods?
Regards Andreas Pokorny
That is close, but the method forwarded to may or may not be virtual. I don't know how the gnu gcc signatures worked, I have only heard second-hand that it was a similar technique. There is an article at http://www.codeproject.com/cpp/retrofitpolymorphism2.asp which explains how the technique works using double-width pointers. There was also an article on it, in the September 2004 issue of the C/C++ Users Journal. Christopher Diggins http://www.cdiggins.com
On Sat, 01 Jan 2005 12:46:07 -0500, christopher diggins <cdiggins@videotron.ca> wrote:
That is close, but the method forwarded to may or may not be virtual. I don't know how the gnu gcc signatures worked, I have only heard second-hand that it was a similar technique. There is an article at http://www.codeproject.com/cpp/retrofitpolymorphism2.asp which explains how the technique works using double-width pointers. There was also an article on it, in the September 2004 issue of the C/C++ Users Journal.
I just have to say that I continue to be astounded by the elegant and useful ideas and code that people on this list come up with on a regular basis. So here are some words of appreciation. Wow! This is neat! Happy New Year Boosters. Thanks for making C++ more fun! -- Caleb Epstein caleb dot epstein at gmail dot com
Reece Dunn wrote:
David Abrahams wrote:
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object.
Python does it too. It's not neccessarily wrong for other languages; just C++.
The heirarchy above is for a UI object, where a UI object has moving/positioning and event handling integral to it. Consider:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base? Here, I was using the namespace as part of the name to denote the role that the class plays, not that it is a monolithic uberclass.
A layout manager that can be moved?? Maybe you have something else in mind, but I understand a layout manager to be a supplier of logic with no graphical representation. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
* David Abrahams <dave@boost-consulting.com> [2004-12-30 14:53]:
Reece Dunn wrote:
David Abrahams wrote:
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object.
Python does it too. It's not neccessarily wrong for other languages; just C++.
The heirarchy above is for a UI object, where a UI object has moving/positioning and event handling integral to it. Consider:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base? Here, I was using the namespace as part of the name to denote the role that the class plays, not that it is a monolithic uberclass.
A layout manager that can be moved?? Maybe you have something else in mind, but I understand a layout manager to be a supplier of logic with no graphical representation.
David, That's the distinction I'm trying to make between renderers and layouts. Reece is discussion a form/frame renderer. The strategy there is to use a tree of nested boxes. Example: Yuumight have a splitter layout containing a NS/EW layout, containing a grid layout (not a grid renderer, but an object that arranges more objects in a fixed grid), in the grid layout you have a list box, it has list items, etc. When the splitter is moved, it changes shape and calls the ES/EW layout, which changes shape and calls the grid layout, which changes shape and calls the list box, which changes shape and calls the list items, which change shape and call... Java AWT, Swing, Delphi all use the term Layout to describe these boxes of boxes. A grid layout is an row/column layout of from controls, it doesn't provied for resizing, sorting, ranges. A flow layout lays out controls left to right, but it doesn't layout text, paragraphs, columns, etc. In this strategy, you are choosing to use memory to model each axis-aligned bounding box as an actual object. This is why I call it the *form* rendering strategy, and draw distinctions between the *grid*, *document*, and *canvas* rendering strategies. That is why I'm talking about rendering, to make the distiction between this simple, but inscalable strategy, and other, more scaleable rendering strategies. There is a place for the *form* strategy, but I don't think it is a foundation for all rendering. Especially not in a generic programming language. -- Alan Gutierrez
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object.
Python does it too. It's not neccessarily wrong for other languages; just C++.
hmm.... If C++ had implemented an 'Object' back in 1980, then "single rooted heirachy"s wouldn't be questioned... Mathew FWIW, the concept of 'flyweght' classes are great -> its a pity that other languages can't get true flyweight semantics.
Mathew Robertson wrote:
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object.
Python does it too. It's not neccessarily wrong for other languages; just C++.
hmm.... If C++ had implemented an 'Object' back in 1980, then "single rooted heirachy"s wouldn't be questioned...
It would, because that 'Object' invented in 1980 would have had virtual functions, which everyone would be forced to pay for. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Mathew Robertson wrote:
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object.
Python does it too. It's not neccessarily wrong for other languages; just C++.
hmm.... If C++ had implemented an 'Object' back in 1980, then "single rooted heirachy"s wouldn't be questioned...
We'd still be using C in that case. ;-) Bad single-rooted hierarchies are bad in principle; it doesn't depend on language. The problem occurs when the base class acquires functionality that 90% of the descendants have. The other 10% are forced to implement something that they do not support. Over time, this can lead to "spectacular" designs. All of the above examples do not fit this description; the root "object" is simply what constitutes an object in that particular language. Since in C++ everything can be an object, the root class is "void".
Python does it too. It's not neccessarily wrong for other languages; just C++.
hmm.... If C++ had implemented an 'Object' back in 1980, then "single rooted heirachy"s wouldn't be questioned...
This is precisely why I brought up the Boost Interfaces Library in my earlier post. We can have every class comptaible with IObject without having to inherit from other classes, and without virtual functions. This provides all of the advantages of a single rooted hierarchy without any of the disadvantages. I already have an object oriented primitive library which leverages this functionality. See http://www.ootl.org/objects.html Christopher Diggins http://www.cdiggins.com
* christopher diggins <cdiggins@videotron.ca> [2004-12-30 20:11]:
Python does it too. It's not neccessarily wrong for other languages; just C++.
hmm.... If C++ had implemented an 'Object' back in 1980, then "single rooted heirachy"s wouldn't be questioned...
I already have an object oriented primitive library which leverages this functionality. See http://www.ootl.org/objects.html
Is that site down? -- Alan Gutierrez - alan@engrm.com
Reece Dunn wrote: Thanks for the summary.. I got tired of trying to follow all the other GUI threads.
We have different people with different needs and ideas as to what constitutes a UI system.
If I was to use some sort of Boost.GUI it would be to implement a zooming interface.
The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems.
The ideal library would allow user customization to account for non traditional interfaces. I don't think we want to be stuck with a library that can't be modified/expanded in the future.
There are several layers to a (G)UI library: [2] The geometry layer - unit type, point, size, rect.
For a zooming-ui there would need to be some form of non 2D aspect. Like Z or Layer component. So making sure that one can redefine/replace/customize the actual definitions of these base types would be essential.
Each of these layers is conceptually independant, but builds on top of the other. Should there be a separate library for each of these layers (Boost.Platform, Boost.Geometry, Boost.Graphics, Boost.Events and Boost.UIObject)?
Definitely. As it would make it that much more useful to others if they case use those parts independently. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Reece Dunn wrote:
There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc.
This is a significant tangent from this conversation. Does anyone think it would be possible/useful to create an event-loop library completely independent of the GUI library, but that the GUI library would use. I think there are probably vast uses other than GUI apps that could take advantage of such a component. Obviously the signal library could be put to good use in such an event library (once the performance optimizations are implemented). This is pretty much just a random thought :) Neal
* Neal Coombes <nealc@trdlnk.com> [2004-12-29 15:29]:
Reece Dunn wrote:
There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc.
This is a significant tangent from this conversation. Does anyone think it would be possible/useful to create an event-loop library completely independent of the GUI library, but that the GUI library would use. I think there are probably vast uses other than GUI apps that could take advantage of such a component. Obviously the signal library could be put to good use in such an event library (once the performance optimizations are implemented).
This is pretty much just a random thought :)
I agree. I'd like to see the form validation broken out, for example, into a validation library, that could be used to validate db inserts, remote form submissions, etc. I'm sure that some of the magic that goes into a vector graphics library could be applied to sundry problem domains. Again, flatter heirarchy. -- Alan Gutierrez - alan@engrm.com
"Neal Coombes" wrote:
[4] The event handling layer - event loop, events, event handlers.
Does anyone think it would be possible/useful to create an event-loop library completely independent of the GUI library, but that the GUI library would use. Yes. There was attempt some year(s) ago but didn't materialize.
Such a library could be used as communication backbone in app made from several DLLs, decoupling their development (for example, if designed generically enough). /Pavel
Pavel Vozenilek wrote:
"Neal Coombes" wrote:
[4] The event handling layer - event loop, events, event handlers.
Does anyone think it would be possible/useful to create an event-loop library completely independent of the GUI library, but that the GUI library would use.
Yes. There was attempt some year(s) ago but didn't materialize.
I believe Aaron LaFramboise is working on a reactor library that will provide a generic backbone for event driven applications. I'v no idea how far he has got, though. Regards, Stefan
Neal Coombes wrote:
Reece Dunn wrote:
There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc.
This is a significant tangent from this conversation. Does anyone think it would be possible/useful to create an event-loop library completely independent of the GUI library, but that the GUI library would use. I think there are probably vast uses other than GUI apps that could take advantage of such a component. Obviously the signal library could be put to good use in such an event library (once the performance optimizations are implemented).
This is pretty much just a random thought :)
Neal
Hi Neal, This is exactly what Glib and Glibmm do. Glib being the C backbone and Glibmm the C++ language binding. Glibmm uses sigc++ as event system and supports all kind of things like polling, timeouts, inputevents and stuff. :) Hagen.
Hagen Möbius wrote:
Hi Neal,
This is exactly what Glib and Glibmm do. Glib being the C backbone and Glibmm the C++ language binding. Glibmm uses sigc++ as event system and supports all kind of things like polling, timeouts, inputevents and stuff. :)
It's possible that's where I stole the idea (we use glib and glibmm excessively :).
Reece Dunn wrote:
Hi All,
We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required.
There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc.
Each of these layers is conceptually independant, but builds on top of the other. Should there be a separate library for each of these layers (Boost.Platform, Boost.Geometry, Boost.Graphics, Boost.Events and Boost.UIObject)?
The design for the UI object layer must be able to support: * native-based UI objects that are dynamically constructed. * native-based UI objects taken from pre-built elements, e.g. objects on a form. * lightweight UI objects that are not native-based. * custom drawn native-based UI objects (either dynamically constructed or from pre-constructed objects), in essence a hybrid of native-based and lightweight UI objects.
All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as:
ui::object ui::frame ui::form ui::main_frame ui::popup ... ui::widget ui::textfield ui::textarea ui::button ui::grid ui::table ... ui::layout_manager ui::flow_layout ...
Oh boy, it looks like another MFC to me. Such single object derived hierarchies usually don't work well. They are hardly scalable. Eugene
Reece Dunn wrote:
Hi All,
We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required.
[...]
The question is how to make it easy to specify both lightweight and native UI objects.
Using a component< render_as< Renderer > > structure does not allow for an easy implementation -- how do you map the implementation details for a specific component and how do you make it extensible?
I do not yet see an easy approach. I am thinking of a PIMPL-style implementation, but using templates to simplify allocation does not allow for easy construction of UI objects. Consider:
I think notus is balancing the platform separation vs. integration issues very well. http://notus.sourceforge.net/ The idea was to define a platform abstraction layer. What is interesting is that the abstraction layer is *parameterized* by traits. Note: the actual platform-dependent implementation is NOT part of traits (the implementation is simply parameterized by traits). The platform is basically a data type that has to provide some interfaces much like type traits in STL. Note: traits can make use of native data types directly. Traits are obviously exposing the native data types to the rest of the library through predefined names. Traits allow the higher levels of the library to process native types *generically*. With traits, the user can easily customize an existing implementation of the abstraction layer or select a different implementation of the layer by simply using traits that an implementation of the layer exists for. Even if necessary, the user can write platform-dependent code at the highest level. For instance if for whatever reasons, the library isn't processing some of the native UI messages, the user can still implement platform-dependent handles at the high level. Eugene
In reference to BoostGUI on the Wiki (http://tinyurl.com/5jexr): I'm a little surprised that nobody responded to my suggestion to complete the survey of existing GUI libraries. http://article.gmane.org/gmane.comp.lib.boost.devel/115717 I'm concerned that unless we explicitly move to structure the conversation now, it will implode. Do you folks think this is a bad idea? Too much work? Or still thinking about it? - Chris "Reece Dunn" <msclrhd@hotmail.com> wrote in message news:cqv0co$l22$1@sea.gmane.org...
Hi All,
We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required.
* Christopher D. Russell <cdr@encapsule.com> [2004-12-29 17:12]:
In reference to BoostGUI on the Wiki (http://tinyurl.com/5jexr):
I'm a little surprised that nobody responded to my suggestion to complete the survey of existing GUI libraries.
I'm concerned that unless we explicitly move to structure the conversation now, it will implode.
Do you folks think this is a bad idea? Too much work? Or still thinking about it?
All over it. A lot of work. Yes. In last three days: ~ Downloaded SWT, wxWindows, win32 generics (John's work), GTK source, Swing source, Safari (apple web core), and stepped through control library of Gecko via LXR. ~ Installed Eclipse CDT for Win32, Linux, Symbian, PalmOS, installed XCode 1.5 for OS X. ~ Built "Hello, World!" windowing applications for GDI, Carbon, Nokia's four separate Symbian SDKs, and PalmOS. ~ Reading through Boost.Build ./kernel/ in order to create a "bundle" rule for Carbon. Learning quite a bit. Trying to share it. -- Alan Gutierrez - alan@engrm.com
* Christopher D. Russell <cdr@encapsule.com> [2004-12-29 17:12]:
In reference to BoostGUI on the Wiki (http://tinyurl.com/5jexr):
I'm a little surprised that nobody responded to my suggestion to complete the survey of existing GUI libraries.
http://article.gmane.org/gmane.comp.lib.boost.devel/115717
I'm concerned that unless we explicitly move to structure the conversation now, it will implode.
Do you folks think this is a bad idea? Too much work? Or still thinking about it?
Christopher, You put out two good questions, top ten hassles, top ten NEW ideas, that I'd like to discuss. As far has hassles go, I think that most object libraries are so frame/widget oriented, they leave almost all the real work to the application developer. -- Alan Gutierrez - alan@engrm.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alan Gutierrez Sent: Wednesday, December 29, 2004 4:58 PM To: Christopher D. Russell Cc: boost@lists.boost.org Subject: Re: [boost] Re: [gui] The Big Picture
As far has hassles go, I think that most object libraries are so frame/widget oriented, they leave almost all the real work to the application developer.
I don't see that you've proposed anything that would leave frames behind. Isn't the frame still the fundamental unit in your view? Aren't layout managers objects that position and size some frames inside of other(s) or have I misunderstood the nature of what you have been describing? -- Noah
* Noah Stein <noah@acm.org> [2004-12-29 18:28]:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alan Gutierrez Sent: Wednesday, December 29, 2004 4:58 PM To: Christopher D. Russell Cc: boost@lists.boost.org Subject: Re: [boost] Re: [gui] The Big Picture
As far has hassles go, I think that most object libraries are so frame/widget oriented, they leave almost all the real work to the application developer.
I don't see that you've proposed anything that would leave frames behind. Isn't the frame still the fundamental unit in your view? Aren't layout managers objects that position and size some frames inside of other(s) or have I misunderstood the nature of what you have been describing?
When I hear layout manager, I think of Delphi or Swing. A layout arranges components on a form. A form is a fixed set of controls within a window of fixed size, or that has a simple resize strategy, since the number of controls does not change. Frames + controls + layouts = Power Builder, Delphi, Visual Basic. Then you have a few frameworks that up the ante with a grid "control", but that is a misnomer, because a grid "control", where it is found, imposes a lot of requirements on the UI library. The library must now implement components that can take part in a grid, there can be many, they can be clipped. Where you see a grid "control", you see a library that has provided it's own set of UI widgets. This is Swing and Delphi VCL. A grid is not a "layout", it is a very complicated rendering engine, and it requires it's own components. I'm talking about putting "layout managers" in their place, *form* layout managers, one strategy to render the contents of a window, and looking at the three other strategies, grid *renderers*, document *renderers*, canvas *renderers*. If by frame, you mean the window frame, is the same fundumental unit as a label, no, because that breaks down if you try to say that a window is the same fundumental unit as a paragraph. If you see a form label and a window as the same beastie, you're making the Win32 GDI mistake. -- Alan Gutierrez - alan@engrm.com
-- Noah
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Heya Chris and everyone!
I'm a little surprised that nobody responded to my suggestion to complete the survey of existing GUI libraries.
I'm unable to edit the Wiki - apparently my IP address is blocked for some reason. Anyways, I wrote on my blog a few other GUI libraries that we should really take a look at, check it out here: http://tinyurl.com/6an9h I will try and find time to comment on MFC, Win32, WinForms and wxWidgets which are the libraries I've had some exposure to.
I'm concerned that unless we explicitly move to structure the conversation now, it will implode.
After being away from the PC for awhile (really, it's healthy sometimes!) and reading up on all the postings about GUI-related topics, I'm a little concerned with how the discussions are heading. I don't think it's that anyone is doing anything wrong, just that the topic is large and I worry that, because of the diverse interests, the discussion may fizzle. Hopefully not. For the record, I'm *definitely* interested in some form of Boost GUI library. Personally, I'd love to see a lightweight, cross-platform, native widget library created. As a _second_step_ I'd like to see a cross-platform 'canvas' library created (allowing the drawing of primitives on the canvas). The canvas component should be able to be hosted within a special widget in the widget library. If we got that far I'd be happy. :) Skinning is not important to me (as it usually detracts from usability) and unit independance isn't such an issue for the widget library (though I think it's critical for the canvas library). So, the widget library should be easier to write - though obviously we need to sort out things like events (John's work here on Win32Gui should be leveraged), layout management and, to a lesser degree, presentation issues like colours and fonts.
Do you folks think this is a bad idea? Too much work? Or still thinking about it?
Not a bad idea. A fair chunk o' work. Thinking about it a fair bit but it won't be consuming all of my spare time until a little way into the New Year. Everyone needs a break! :) Sorry for the rambling message! Cheers, Matt
* Marcelo E. Magallon <mmagallo@debian.org> [2004-12-30 10:02]:
On Fri, Dec 31, 2004 at 12:00:45AM +1100, Matt S Trentini wrote:
Personally, I'd love to see a lightweight, cross-platform, native widget library created.
That's something that's been bugging me...
How would be that any different from wxWidgets?
Lowercase variable names, and underbars, but otherwise, not. -- Alan Gutierrez - alan@engrm.com
Marcelo E. Magallon wrote:
That's something that's been bugging me...
How would be that any different from wxWidgets?
wxWidgets is my pick of the (many!) libraries that help write cross-platfrom C++ code but it's far from perfect. I do'nt have a lot of time right now (just about to head away to celebrate New Years!) but here's a couple of issues I have with it off the top of my head: o Event system is ugly - An event table like MFC's? No thanks. - Signals are a much neater solution. o wxWindows avoids newer coding techniques - Using templates and C++ RTTI would have cleaned up their code - Again, understand that those features weren't very portable but we're in a different situation today o Standard library avoidance - They reimplemented vector, string etc for the same reasons as the last point o Huge class list, difficult to find the classes you're looking for - Namespaces would have alleviated this issue - Also overextends it's bounds - I don't believe it should have networking and date/time classes for example o wxWidgets is not exception safe - (Nor are exceptions used within the library) o wxWidgets is not thread safe or thread aware - Or it wasn't the last time I used it, from memory some people were working on it... Don't get me wrong, wxWindows offers a great deal and is a very rich library. But it has room for improvement, particularly with the event subsystem. Gotta run! Cheers, Matt
Matt S Trentini wrote:
Marcelo E. Magallon wrote:
That's something that's been bugging me...
How would be that any different from wxWidgets?
wxWidgets is my pick of the (many!) libraries that help write cross-platfrom C++ code but it's far from perfect. I do'nt have a lot of time right now (just about to head away to celebrate New Years!) but here's a couple of issues I have with it off the top of my head:
o Event system is ugly - An event table like MFC's? No thanks. - Signals are a much neater solution.
In the next development cycle (wxNG) they are planning to rewrite that. And they are considering using Boost.Signal as the signal library, or something like it.
o wxWindows avoids newer coding techniques
The current development version is moving towards newer coding styles.
- Using templates and C++ RTTI would have cleaned up their code - Again, understand that those features weren't very portable but we're in a different situation today
Don't know how much of that they plan to rewrite in wxNG, but it has been mentioned.
o Standard library avoidance - They reimplemented vector, string etc for the same reasons as the last point
In the current dev they have support for the wx equivalents of some of those to just be typedef equivalents. That is they have an std compatible interface and in some cases are implemented as shells around the std types. The intent is to continue moving more out of wx that is now part of the standard or other libraries like Boost.
o Huge class list, difficult to find the classes you're looking for - Namespaces would have alleviated this issue - Also overextends it's bounds - I don't believe it should have networking and date/time classes for example
But of course other people think otherwise ;-) And at least you can disable much functionality if you don't need it.
o wxWidgets is not exception safe - (Nor are exceptions used within the library)
No clue if they are planning to address that.
o wxWidgets is not thread safe or thread aware - Or it wasn't the last time I used it, from memory some people were working on it...
It's thread safe in the sense that you have to do everything GUI related in the main/GUI thread. I really hate that aspect.. but I cope with it :-) All that is of course AFAIK. I don't fastidiously follow the wx dev list so I may be misinformed in places. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Heya Rene, That all sounds great; perhaps we should be helping out the wx guys rather than come up with our own library...? Does anyone else have any good reason why we should create a completely new library assuming that those issues are addressed? (License could be one problem quite aside from the technical issues.) Keep in mind that starting a GUI library from scratch is going to take *significant* time. And is wxWindows our "best bet"? It's certainly going to be easier than trying to convince the Qt folks to get rid of their preprocessor... ;) It'd be fantastic if all the issues I brought up with wxWidgets were addressed and we ensured that it worked well with the other boost libraries. Is there anything anyone else wants or needs that wxWidgets couldn't supply? Cheers, Matt PS I've started looking through the wx developer archives. Interesting. They seem to be very much in the 'early days' and moving quite slowly (one guy mentioned that he expected wxTNG (aka wxWidgets 3.x) to be delivered in 2-3 years!) but they do appear to be interested in working alongside boost - there was even a tongue-in-cheek suggestion that they submit the next revision as "boost-gui"! Check out the following threads: http://tinyurl.com/533w6 http://tinyurl.com/4ht5q http://tinyurl.com/6a7us http://tinyurl.com/4ajfy It's worth noting that there didn't seem to be much discussion on the list about wxTNG - they seem to (understandably) be more concerned with bugfixing and ongoing development of the current builds. They do seem to be interested in using more modern C++ features and exception safety was mentioned. Oh, also, Hajo Kirchhoff (of Lit GUI library fame) has been active on both the boost and the wx developer discussion lists, trying to determine if the two groups can leverage resources. See here for his boost posting (his wx postings are included in the above links): http://tinyurl.com/3zwxs A collaboration sounds like a great idea to me...
"Matt S Trentini" <matt_trentini@yahoo.com.au> wrote in message news:cr0u54$ll4$1@sea.gmane.org...
Heya Chris and everyone!
I'm a little surprised that nobody responded to my suggestion to complete the survey of existing GUI libraries.
I'm unable to edit the Wiki - apparently my IP address is blocked for some reason.
Me too .OTOH I havent used wiki before so maybe I'm doing something wrong? I get a message telling me I dont have access and to inform the administrator. Is the boost wiki only for an exclusive set? Whatever I have always found the http://www.fresco.org project (used to be called moscow) interesting, though it may be a classic instance of one of the dangers of top down design( It does everything right in theory , but is unfinished and overcomplex for users). regards Andy Little
"Matt S Trentini" <matt_trentini@yahoo.com.au> wrote in message news:cr0u54$ll4$1@sea.gmane.org...
Heya Chris and everyone!
I'm a little surprised that nobody responded to my suggestion to complete the survey of existing GUI libraries.
I'm unable to edit the Wiki - apparently my IP address is blocked for some reason.
Me too .OTOH I havent used wiki before so maybe I'm doing something wrong? I get a message telling me I dont have access and to inform the administrator. Is the boost wiki only for an exclusive set? Whatever I have always found the http://www.fresco.org project (used to be called moscow) interesting, though it may be a classic instance of one of the dangers of top down design( It does everything right in theory , but is unfinished and overcomplex for users). regards Andy Little
Matt S Trentini wrote:
Heya Chris and everyone!
I'm a little surprised that nobody responded to my suggestion to complete the survey of existing GUI libraries.
I'm unable to edit the Wiki - apparently my IP address is blocked for some reason. Anyways, I wrote on my blog a few other GUI libraries that we should really take a look at, check it out here:
I will try and find time to comment on MFC, Win32, WinForms and wxWidgets which are the libraries I've had some exposure to.
I'm concerned that unless we explicitly move to structure the conversation now, it will implode.
After being away from the PC for awhile (really, it's healthy sometimes!) and reading up on all the postings about GUI-related topics, I'm a little concerned with how the discussions are heading. I don't think it's that anyone is doing anything wrong, just that the topic is large and I worry that, because of the diverse interests, the discussion may fizzle.
Hopefully not.
For the record, I'm *definitely* interested in some form of Boost GUI library.
Personally, I'd love to see a lightweight, cross-platform, native widget library created. As a _second_step_ I'd like to see a cross-platform 'canvas' library created (allowing the drawing of primitives on the canvas). The canvas component should be able to be hosted within a special widget in the widget library.
If we got that far I'd be happy. :)
Skinning is not important to me (as it usually detracts from usability) and unit independance isn't such an issue for the widget library (though I think it's critical for the canvas library). So, the widget library should be easier to write - though obviously we need to sort out things like events (John's work here on Win32Gui should be leveraged), layout management and, to a lesser degree, presentation issues like colours and fonts.
Not sure anyone is interested, but I intend to separate the UI from the window concept. In other words, how a control (or widget, if you like) behaves from how a control is shown visually. This will take care of both rendering and resizability. Then, will implement some CSS on top of that. Alan Gutierez has agreed to help me, so in 1-2 months, something should come out. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- http://www.torjo.com/cb/ - Click, Build, Run!
participants (21)
-
Alan Gutierrez -
Andreas Pokorny -
Andy Little -
Caleb Epstein -
Christopher D. Russell -
christopher diggins -
David Abrahams -
E. Gladyshev -
Hagen Möbius -
Jody Hagins -
John Torjo -
Marcelo E. Magallon -
Mathew Robertson -
Matt S Trentini -
Neal Coombes -
Noah Stein -
Pavel Vozenilek -
Peter Dimov -
Reece Dunn -
Rene Rivera -
Stefan Seefeld