Re: [boost] Re: GUI library - another one

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2004-03-04 14:36:42

--- Robert Ramey <ramey_at_[hidden]> wrote:
> I believe similar discussions were engaged some time ago and that these
> discussions resulted in:
> 
> http://sourceforge.net/projects/notus/
> 
> What to the participants in these other discussions have to add?

Well, I am quite happy with the direction notus is taking
but there is a lot to be done.

First I'd like to comment on the issue of simplicity.
Simplicity is great but IMHO, it should NOT be 
of concern of the core GUI design. The higher layers could
simplify the core interface any way they like.
Like another poster pointed out if a feature is missing
it could easily be a showstopper.
It is like missing a letter in the alphabet.
The primary concern of the core GUI design should be
consistency, *scalability* and feature support.

I think that the discussion of the syntax like 
using operators '<<' or '[]' and so on is important
but it is a secondary issue.

I think that what we are missing a consistent fundamental 
GUI design. All this syntactic sugar or XML support
could be added at a latter stage.
Most of the GUI frameworks with their endless
polymorphic hierarchies and castings are not
fun anymore. :)

The fundamental GUI library doesn't have
to support all possible features right from
the start. It is more important to identify
all fundamental features and architectures that will let
you to scale the framework up with new features.
Usually a GUI feature is not a standalone thing. 
It relies on presence of other features. 
A good GUI library should identify a set 
of *fundamental*  features and architectures 
that will let the library grow vertically
and orthogonally.

Notus is based on what we call MDS
(the DDV terminology will be deprecated).

Model  - application data
Display  - physical device such as window, button
Strategy - user defined behaviors

template <typename Model, typename Display, typename Strategies >
struct view {...}

A typical strategy looks like this

struct my_strategy : 
        handle_event<mouse>
        handle_event<paint>
{
        template< typename View >
        void on_event( View& v, mouse& e);

        template< typename View >
        void on_event( View& v, paint& e);
};

As you can see, the strategy event handlers 
take the event source (View) as a template
parameter. So as soon as the View provides
the interface that is required by this strategy, 
it doesn't care what View really is. 
So strategies can be used as interchangeable components.
Strategies can be combined and reused.

typedef view< my_data, displays::window, tuple<my_strategy> > my_window;

//customize my_window
typedef view
        < my_data, 
          displays::window, 
          tuple<my_customization, typename my_window::strategy> > my_custom_window;

//my_custom_window reuses all strategies that are defined in my_window;

I'd like to note that notus doesn't have any 
casting stuff and almost no polymorphism.
The idea is to create a *generative* framework
where components can be constructed from
a set of interchangeable and custom parts.

I'd like to touch the issue of ownership.
The core Notus doesn't care about ownership at all,
the physical devices such as windows, buttons, etc.
are represented by Displays.
One display can be connected to one or more 
other displays so that it will get events 
generated by the displays that it is connected to.
So at this level, it is a *network* of
display connections not an ownership hierarchy.

I anticipate your question
What happens if the GUI object is physically 
deleted by its physical owner.
Nothing really except that the connection
doesn't exist anymore.

*Important* the displays don't keep direct 
references to other displays.

I appreciate your comments.

Eugene

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com