Bill Baxter wrote:
> Tom S wrote:
>> Bill Baxter wrote:
>>>> It used/uses an event processing system called 'sinking and bubbling' which is superior to anything in existence ;)
>>>
>>> Gee thanks, that really clears it up for me.  :-P
>>>
>>> But you're wrong anyway.  Few people know it, but the most superior event processing system ever was the 'skulking and babbling' system invented at Xerox Parc, and promptly forgotten.  By everyone. :-P
>>
>> LOL :D Well, the concept was explained here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.dwt&artnum=61 
> 
> 
> Ah, ok.  Makes sense now.   Yes that is nice.  It drives me mad in wxWidgets that only that *one* widget gets the event, except .  I can't remember what Qt does there.


I can't either, but the sinking/bubling reminds me of how GTK+ handles events -- although I think that there the traversal is only unidirectional. Every widget in the chain can act on an event, and either stop the traversal (handled) or let it bubble further up the chain. There is also a filtering mechanism, so widgets can be configured to never receive events that they are not interested in.

Good to know that wxWidgets has that limitation. We have considered using it, but went for GTK+ instead.


Bastiaan.

Bastiaan Veelo wrote:
> Bill Baxter wrote:
>> Tom S wrote:
>>> Bill Baxter wrote:
>>>>> It used/uses an event processing system called 'sinking and bubbling' which is superior to anything in existence ;)
>>>>
>>>> Gee thanks, that really clears it up for me.  :-P
>>>>
>>>> But you're wrong anyway.  Few people know it, but the most superior event processing system ever was the 'skulking and babbling' system invented at Xerox Parc, and promptly forgotten.  By everyone. :-P
>>>
>>> LOL :D Well, the concept was explained here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.dwt&artnum=61 
>>
>>
>>
>> Ah, ok.  Makes sense now.   Yes that is nice.  It drives me mad in wxWidgets that only that *one* widget gets the event, except .  I can't remember what Qt does there.
> 
> 
> I can't either, but the sinking/bubling reminds me of how GTK+ handles events -- although I think that there the traversal is only unidirectional. Every widget in the chain can act on an event, and either stop the traversal (handled) or let it bubble further up the chain. There is also a filtering mechanism, so widgets can be configured to never receive events that they are not interested in.

Yeh, actually this is the first I've heard of a toolkit that percolates both down and then up.  But I'd guess percolating up starting with the deepest widget probably covers 90% of practical cases.

> Good to know that wxWidgets has that limitation. We have considered using it, but went for GTK+ instead.

wxWidgets does percolate some kinds of events up the chain like command events.  Like if you click on a button you get that event at the button, at the parent, and on up until someone says they handled it.

But if it makes sense to do it for those kinds of things then it makes sense to do it for everything.

--bb

Bill Baxter wrote:
> Julio César Carrascal Urquijo wrote:
>> Lutger wrote:
>>> You can, instead of using a frame-based approach, repaint as needed. The lack of state is in the interface, behind the scenes a library can do caching. I don't remember the link, but there was some guy who rewrote his traditional gui for a cellphone to an imgui one, and stated that performance was about the same.
>>>
>>> One benefit though is that in normal gui's, a whole lot a state is retained and duplicated between the application and the gui library. In complex application, that sucks performance.
>>>
>>
>> All the implementations I've seen use real-time redrawing which is obviously overkill for this type of application. But you are right, it is certainly possible.
> 
> Casey does mention it as a drawback of immediate mode GUI in the video.  If you want lazy updates, the burden of implementing it is on the application as opposed to retained mode GUIs where the toolkit can handle it for you.  But even then a lot of GUI systems have some sort of update() or refresh() call that you have to remember to call to tell it that something changed.  So it's not that different I don't think.
> 
> --bb

In my toy imgui, I only update when there are events, and even then only when some state has changed the thing need to be rendered again. This is all behind the scenes though, so the user doesn't have to do anything. This is lazy enough in practice, I guess it's a trade between executing the gui logic on every event in the imgui case and retaining state in rmgui.

Lutger wrote:
...
> In my toy imgui, I only update when there are events, and even then only when some state has changed the thing need to be rendered again. This is all behind the scenes though, so the user doesn't have to do anything. This is lazy enough in practice, I guess it's a trade between executing the gui logic on every event in the imgui case and retaining state in rmgui.

To clarify, state in imgui is handled mostly implicitly by the library and is usually a small constant, while with rmgui the user has to do bookkeeping herself and the state involved grows proportionally with the size of the gui.

Bill Baxter wrote:
> (with a nod to Don ;)
> No, I don't have the perfect GUI.
> I'm just throwing this out as a topic for discussion.  I've yet to find
> a GUI that isn't tedious to use.  With 2.0 const hopefully nearing
> completion, and the new closure support in 2.0, maybe it's a good time
> to dream again about what the ultimate D GUI would look like.
> 

I was thinking maybe we can learn something from Ruby on rails !

All the app needs to define is the model, then the framework define the control and the view.

First the apps menues is just a way to call functions.
new appdata file_new();
void file_save(const appdata , filename afilename);
void file_save_as(const appdata , const filename afilename);
new (appdata,filename afilename)  file_open(filename);

Would define the file menu with new,save, save_as and open,
the app. should only specify the apps functionality every thing
else should be themed an styled via the gui framework or by the desktop
or window manager.


The first line:
new appdata file_new();
tell the framework that selecting the menu file->new create a new
container of type appdata, the styling of the gui framework decide if
this is done in a new window or tab.

The next line:
void file_save(const appdata , filename afilename);
tells the gui to open at dialog which allow a filename to be chosen
and use the content of afilename as a default.
const appdata tells the gui that the dialog should not edit appdata.

The line:
new (appdata, filename afilename)  file_open(filename);
tells the gui to open the file dialog and then load the file into a new
container.

Hope this is understandably.

Knud

Ary Borenszweig wrote:
> Bill Baxter wrote:
>> (with a nod to Don ;)
>> No, I don't have the perfect GUI.
>> I'm just throwing this out as a topic for discussion.  I've yet to find a GUI that isn't tedious to use.  With 2.0 const hopefully nearing completion, and the new closure support in 2.0, maybe it's a good time to dream again about what the ultimate D GUI would look like.
> 
> I like lots of ideas from WPF: http://en.wikipedia.org/wiki/Windows_Presentation_Foundation

Could you sum them up here, the ones you like most?

Bastiaan.

Op Thu, 29 Nov 2007 02:27:52 +0100, schreef Tom S:

> Sure thing! I used that in Deadlock. The nesting is mainly due to use of many VBoxes and HBoxes (like in GTK) for layout. If I figure out how to do layout better, that might as well get pretty flat.

Gtk also has grid/table layouts, and some programmes and libraries migh have additional layout containers (e.g. column containers that balance their subitems over a number of columns).


-- 
JanC

not that it might end all GUI libs, but i was starting to write a Qt-ish GUI framework (i.e. signals&slots) that can load widget layouts from e.g. XML files at runtime (signal connection at runtime using runtime reflection). rendering will be done with OpenGL, but is abstracted s.t. any renderer can be added.
i ran out of time, but i'll need it in a future not too far away and continue work on it then.