RE: [boost] GUI library - another one

From: David Turner (dkturner_at_[hidden])
Date: 2004-03-03 13:17:30

Hi

> Shrug.  I'm not a GUI person, in large part because every 
> time I look  into it,
> I end up deciding that it's far more work to learn how to use 
> than the  benefits
> would justify.  A boost-supported cross platform GUI would 
> definitely  go far in
> addressing the issue of not wanting to invest time learning 
> something  which is
> largely tied to a single platform.  But what  I'd really like 
> to see is  a system that allows
> one to accomplish conceptually simple things in a correspondingly  
> simple way, with sensible default behavior of any aspects
> which aren't explicitly  specified and a minimum
> of exposed implementation details to contend with.  While window may  
> very well be implemented as a pointer, I don't see how that
> fact should be relevant to the user  
> of the library (other than, I suspect, historical antecedents).

I agree 100%.  Simple things should be done in simple ways.  I have no
problem with using the following syntax:

window w("my window");
label l("Some text");
w.contain(l);

The only real "gotcha" here is that w is a copyable type that refers to
a shared resource - you don't get a new window by copying an existing
one.  I'm not sure how well this plays with the user's expectations.
That's why I preferred pointer syntax initially (so that the idea stays
in the user's mind that he's using a reference type).

> I would be willing to sacrifice added complexity of 
> implementation to  
> have a more
> intuitive syntax.  Unless I'm reading this wrong, what
> 
> wait_for_signal(w->delete_signal)
> 
> is trying to say is that w should wait for a generic delete signal -  
> that is, delete_signal isn't
> really something that belongs to the window type but is instead an  
> abstract directive to a

Er... I don't really see how you could arrive at that interpretation.
To me, it's quite clear:  wait_for_signal().  Which signal?  W's
delete_signal.

In an earlier incarnation of the library, I had this:

        w->wait_for_close();

There are several problems with this, however, which should be obvious.
On the whole, I prefer wait_for_signal.

Regards
David Turner