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