Re: [boost] Re: GUI library - another one
At 12:10 PM 3/4/2004, David Turner wrote:
... A button in one window isn't necessarily the same thing as a button in another window; just as a bold font in one document isn't necessarily the same as a bold font in another.
I'd rewrite that as "The implementation of a button in one window isn't necessarily the same thing as the implementation of a button in another window..." To modify Dave's example to make a point: button OK_button("OK"); window_one("Warning: now entering twilight zone one") [ text_field("my favorite color is:"), OK_button | button("cancel") | attribute_x(1) ] window_two("Warning: now entering twilight zone two") [ text_field("my favorite color is:"), OK_button | button("cancel") | attribute_x(2) ] Perhaps the implementation of OK_button in window_one is very different from window_two. But they both have OK_buttons, and at the interface level these are the same button.
One cannot say in general that elements can be exchanged between documents. Similarly, one cannot say in general that widgets can be exchanged between windows.
I understand that the implementation details can't be exchanged. But we aren't taking about implementations of buttons, we are talking about the abstract concept of an OK_button. That certainly could be transferred, couldn't it? More importantly, you could build up a widget library which could be used regardless of the target window. Sorry if I'm missing something here; I'm not much of a GUI programmer. --Beman
Hello Beman Dawes wrote:
I understand that the implementation details can't be exchanged. But we aren't taking about implementations of buttons, we are talking about the abstract concept of an OK_button. That certainly could be transferred, couldn't it? More importantly, you could build up a widget library which could be used regardless of the target window. Sorry if I'm missing something here; I'm not much of a GUI programmer.
Okay... I have an idea for how this could be done. I confess I'm biased against it, due to the difficulties and inefficiencies it raises in the implementation. How's this (syntax as of tonight - I'll upload it tomorrow): window w("Test Window"); grid g(2, 2); w.contain(g); g.contain(button("Click me", on_click), 1, 1); g.contain(label("Enter your name:"), 0, 0); textentry t(); g.contain(t, 1, 0); wait_for_signal(w.delete_signal()); // note () after delete_signal Regards David Turner
window w("Test Window"); grid g(2, 2); w.contain(g); g.contain(button("Click me", on_click), 1, 1); g.contain(label("Enter your name:"), 0, 0); textentry t(); g.contain(t, 1, 0); wait_for_signal(w.delete_signal()); // note () after delete_signal
I like this syntax a lot. It's basically transparent to me as a non-GUI person, and I can easily envision how one would extend it. Three comments : 1) if a widget was capable of responding to multiple events, presumably you'd do something like this, right? g.contain(widget("do something",on_click | on_mouseover | on_mousemove),1,1); 2) textentry t; g.contain(t,1,0); is essentially equivalent to g.contain(textentry(),1,0);? 3) rather than having two arguments for grid position, how about a position class with x() and y() members or something like that? I think that would make the code more nearly model the abstraction... Your design also seems to offer a natural way to recursively nest stuff, too, which is nice : grid g2(1,3); g.contain(g2,pos(0,1)); Another possibility which would be interesting is a layer which allows the GUI to be scripted...no idea how easy or hard it would be to implement, though... ------------------------------------------------------------------------ --------------------------- 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
David Turner wrote:
Okay... I have an idea for how this could be done.
I confess I'm biased against it, due to the difficulties and inefficiencies it raises in the implementation.
How's this (syntax as of tonight - I'll upload it tomorrow):
window w("Test Window"); grid g(2, 2); w.contain(g); g.contain(button("Click me", on_click), 1, 1); g.contain(label("Enter your name:"), 0, 0); textentry t(); g.contain(t, 1, 0); wait_for_signal(w.delete_signal()); // note () after delete_signal
You don't have any comments on the syntax suggestion I posted? http://article.gmane.org/gmane.comp.lib.boost.devel/34441 -- Arvid Norberg
On Thu, 4 Mar 2004, Arvid Norberg wrote:
David Turner wrote:
Okay... I have an idea for how this could be done.
I confess I'm biased against it, due to the difficulties and inefficiencies it raises in the implementation.
How's this (syntax as of tonight - I'll upload it tomorrow):
window w("Test Window"); grid g(2, 2); w.contain(g); g.contain(button("Click me", on_click), 1, 1); g.contain(label("Enter your name:"), 0, 0); textentry t(); g.contain(t, 1, 0); wait_for_signal(w.delete_signal()); // note () after delete_signal
You don't have any comments on the syntax suggestion I posted?
I do :) I'm solidly behind the proposals to use a DSEL for describing GUI elements. It's the right level of abstraction for the task. I'm not sure I'm a big fan of the '+' syntax you propose, if only because it requires a lot of discipline to make it look "right", whereas an approach that uses, e.g., [] or () to perform grouping will at least make my editor do the right thing. Doug
"David Turner" <dkturner@telkomsa.net> writes:
How's this (syntax as of tonight - I'll upload it tomorrow):
window w("Test Window"); grid g(2, 2); w.contain(g); g.contain(button("Click me", on_click), 1, 1); g.contain(label("Enter your name:"), 0, 0); textentry t(); g.contain(t, 1, 0); wait_for_signal(w.delete_signal()); // note () after delete_signal
It's not the clear, declarative description of the window that I'm looking for. Looks too procedural to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Arvid Norberg -
Beman Dawes -
David Abrahams -
David Turner -
Douglas Paul Gregor -
Matthias Schabel