Re: [boost] Re: [gui] The Big Picture

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-30 13:04:36

* Reece Dunn <msclrhd_at_[hidden]> [2004-12-30 12:39]:
> Jody Hagins wrote:
> >On Thu, 30 Dec 2004 08:25:51 +0000
> >Reece Dunn <msclrhd_at_[hidden]> 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_at_[hidden]