Re: [boost] GUI library - another one

From: Matthias Schabel (boost_at_[hidden])
Date: 2004-03-03 12:18:06

> Many C++ people like shallow copy things to explicitly have a  
> pointer-like
> syntax. I, personally, can happily tolerate either.
>
> For an apples to apples comparison,
>
>     window w("Example window");
>
> should be compared with
>
>     window w = create_window("Example window");

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).  Of course, I understand that  
I'm an atypical
programmer in that the bulk of my code is written solely for my own use  
or the use of
other scientists rather than end users, and a GUI would be nice but is  
nonessential.

>     w.wait_for( delete_signal() );
>
> just introduces a redundant top-level tag class and a corresponding
> redundant window_base overload.

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
window (or button or widget or whatever) to delete itself.  What it  
actually says to me, on
reading it, is that the main program is waiting for a signal from w to  
quit running.  Anyway,
bear in mind that this is all coming from a computational physicist  
with no real experience
in GUI programming who'd love to see something simple and intuitive  
appear.

------------------------------------------------------------------------ 
---------------------------
Matthias Schabel, Ph.D.                           	
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT  84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu