Re: [boost] GUI library - another one

From: David Turner (dkturner_at_[hidden])
Date: 2004-03-07 12:28:36

Hello

Peter Dimov wrote an excellent post to which I can only say "Hoor,
hoor!" (which means the same as "hear, hear", only it's a little less
understated than the English ;-)).

I think the primitives that appear on-screen should map as directly as
possible to the C++ constructs that represent them.  Most importantly,
their lifetimes should be the same.  This means, for example, that the
window should not disappear automatically just because the user clicked
on the little "X" in the title bar.  That action is properly represented
as a signal - a notification of the user's desire to have the window
closed.  What actually happens after the signal is generated is up to
the programmer.

I've tried to make explicit the fact that the lifetime of the program as
a whole is governed by a (possibly quite complicated) boolean
condition.  Thus instead of, say, MFC's DoModal() method, we have the
more generic wait_for_signal construction, or wait_for_bool_condition:

gui::util::boolean_condition time_to_close;

void do_exit()
{
    time_to_close = true;
}

window w("Example");
w.contain(button("Exit", &do_exit));
w.delete_signal().connect(&do_exit);
wait_for_bool_condition(time_to_close);

The gui C++ objects are not abstract representatives of the _properties_
of the widgets, they represent the widgets themselves.

A property representation/DSEL is perfectly possible, it's just outside
the scope of what I'm trying to achieve.  I also agree with Peter that
making the appearance part of the code is (apart from trivial cases) a
fundamentally flawed approach.  Better is to implement some sort of
serialization schema a la Glade XML.  Again, this is outside of the
scope of the gui library proper.

There is one issue that I think would benefit from some serious debate,
because there is a reasonable case to be made for both sides:

>
> In our case, given a GUI architecture that does not support unowned/free
> widgets and clearly distinguishes between ownership and containment, a Hello
> World program must clearly communicate these principles to the user.

On the whole, I think the fact that there should be ownership semantics
in a GUI library is totally counterintuitive.  It took me a long time to
"know" in a visceral sense the difference between an Owner and a Parent
(in Windows parlance).  It still doesn't make sense in many ways.  I
agree with David Abrahams that this sort of detail should be hidden away
from the user.  Metaphors shouldn't leak;  Donald Norman's advice
applies equally to programmers designing interfaces for other
programmers :-).

On the other hand, I'm not sure that we should be encouraging
programmers to copy-paste elements between windows.  Two windows aren't
necessarily implemented the same way.  Why should their elements be
compatible?  The idea of the window as the entry-point to the
implementation, and as the factory for all other elements, is quite
appealing.  And of course there are the implementation efficiencies ;-).

http://www.w3.org/DOM/faq.html#ownerdoc

At the end of the day, the strongest argument for encouraging the
owner-window model is the practical one.  Thus if I were forced to
concede that practical issues should not make a difference to the
design, I must conclude that the owner-window model is not the right
one.

I'd like to hear some more comments about this, from both sides.  In the
mean time, I'm implementing a free-widget version of the library, which
I'll release later tonight as concept-3.  Depending on which way the
discussion goes, the first testing release can branch off from either
concept-2 or concept-3.

Regards
David Turner