[boost] Re: GUI library - another one

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-03-04 23:53:55

--- Robert Ramey <ramey_at_[hidden]> wrote:

It seems that my post didn't make it through.
I got the Boost post acknowledgement but the message
did not appear on the list. I am trying to use another e-mail account.
If the mailing list moderators would like to look into this problem,
please e-mail me privately so I could give you my account information.
Thanks.

Anyway back to the GUI stuff.

> 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 about what happens
when the display's "physical" owner is deleted.
Nothing really except that all the connections
to the deleted display are lost.

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

I appreciate your comments.

Eugene