View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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.
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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.
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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.
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 29, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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.
November 30, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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
November 30, 2007
Re: The GUI to end all GUI libraries (Let's Dream!)
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.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home