From: David Turner (dkturner_at_[hidden])
Date: 2004-03-03 13:17:30
> 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");
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
> 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
In an earlier incarnation of the library, I had this:
There are several problems with this, however, which should be obvious.
On the whole, I prefer wait_for_signal.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk