Jump to page: 1 24  
Page
Thread overview
The GUI to end all GUI libraries (Let's Dream!)
Nov 27, 2007
Bill Baxter
Nov 27, 2007
0ffh
Nov 27, 2007
Lutger
Nov 27, 2007
0ffh
Nov 27, 2007
Bill Baxter
Nov 28, 2007
0ffh
Nov 28, 2007
Bill Baxter
Nov 29, 2007
Tom S
Nov 29, 2007
Bill Baxter
Nov 29, 2007
Tom S
Nov 29, 2007
Bill Baxter
Nov 29, 2007
Bastiaan Veelo
Nov 29, 2007
Bill Baxter
Nov 30, 2007
Jan Claeys
Nov 29, 2007
Bill Baxter
Re: The GUI to end all GUI libraries (Let's Dream!) [semi-OT]
Nov 29, 2007
0ffh
Nov 29, 2007
Tom S
Nov 27, 2007
Bill Baxter
Nov 27, 2007
Lutger
Nov 27, 2007
Lutger
Nov 28, 2007
Bill Baxter
Nov 29, 2007
Lutger
Nov 29, 2007
Lutger
Nov 27, 2007
Bill Baxter
Nov 27, 2007
0ffh
Nov 27, 2007
Bill Baxter
Nov 27, 2007
Clay Smith
Nov 27, 2007
Christopher Wright
Nov 27, 2007
Bruce Adams
Nov 27, 2007
Maël
Nov 27, 2007
Knud Soerensen
Nov 27, 2007
Ary Borenszweig
Nov 29, 2007
Bastiaan Veelo
Nov 29, 2007
Knud Soerensen
Nov 30, 2007
Jascha Wetzel
November 27, 2007
(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 don't have anything concrete, but I was thinking a bit about some interesting GUI-ish things from Python recently and thought I'd mention them here.

There's a library called "Trellis" [1] that I think has an interesting idea for how to maintain GUI state.

The basic idea is that you define rules rather than explicit event handlers, and execution of those rules is triggered by built-in dependency analysis.  The analogy made on the web page is to a spreadsheet.  When you use a spreadsheet you just say how the values in this cell depend on all the others and then it all gets automagically updated for you recursively whenever any dependency changes.

So I wonder if something like this could be done in D.  Or is there something about the dynamic nature of Python which allows this sort of idea, but makes it unworkable in a static language like D?

Anyway it's a neat idea that seems to me to have potential to take us beyond the same old event-driven paradigm that's been rehashed for years and starts to get quite cumbersome beyond a certain point.

Another interesting GUI-related lib from Python-land that I have my eye on is Traits from Enthought [2].  Traits are sort of objects that wrap a state value and automatically generate callbacks.  So the core actually doesn't have anything to do with GUI-ness.  More like a mechanism for state managment + signals.  But Traits also work with TraitsUI to create GUIs automatically from your Traits with very little extra coding.  That part seems quite useful for creating quick GUI scripts and mockups, but less useful for creating a big app like an IDE.  I haven't worked with Traits much, though, so maybe it scales up better than I think.


--bb

Links:
[1] http://cheeseshop.python.org/pypi/Trellis/0.5b1
[2] http://code.enthought.com/traits/
November 27, 2007
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 recently met someone [1] on IRC asking nearly exactly the same
question, who is working one something. I suppose this is going
to be an interesting discussion...

regards, frank

[1] I won't disclose his identity, but I suppose he'll word up... =)

November 27, 2007
Another interesting idea is immediate mode gui. It basically means that no or almost no state is maintained, at least as far as the user is concerned. Instead, the gui is recreated as needed. I've been playing a bit with it and it works nicely, but somehow I had some trouble with more complex gui's.

Here's a link, the video is worth it imo:

https://mollyrocket.com/forums/viewtopic.php?t=134
November 27, 2007
Lutger wrote:
> Another interesting idea is immediate mode gui. It basically means that no or almost no state is maintained, at least as far as the user is concerned. Instead, the gui is recreated as needed. I've been playing a bit with it and it works nicely, but somehow I had some trouble with more complex gui's.
> 
> Here's a link, the video is worth it imo:
> 
> https://mollyrocket.com/forums/viewtopic.php?t=134

Recently on IRC:

[02:17] <*******> it will have arbitrary theming, backends/rendering engines, probably arbitrary shapes for windows and widgets, easy new widget creation, immediate mode interface, will be extremely configurable, etc, etc :P

Whoa, I hope ******* will forgive me this...
The GUI is a work in progress, and I don't want to bugger up his timing.
Therefore I'll mention it no more. =)

regards, frank
November 27, 2007
Also, I've been quite satisfied with DFL, which is a
mature solution for Windows and moving towards the Xes.

regards, frank
November 27, 2007
0ffh wrote:
> 
> Also, I've been quite satisfied with DFL, which is a
> mature solution for Windows and moving towards the Xes.

I've started using DFL too.  It seems to be the easiest thing to use right now.  But it's still pretty typical in its event driven design, and lacks many convenience features I've become accustom to in other toolkits.  Things like managing tooltips, status messages, and gui state updates (e.g. whether a menu item should show checked/unchecked based on current state).

--bb
November 27, 2007
0ffh wrote:
> Lutger wrote:
>> Another interesting idea is immediate mode gui. It basically means that no or almost no state is maintained, at least as far as the user is concerned. Instead, the gui is recreated as needed. I've been playing a bit with it and it works nicely, but somehow I had some trouble with more complex gui's.
>>
>> Here's a link, the video is worth it imo:
>>
>> https://mollyrocket.com/forums/viewtopic.php?t=134
> 
> Recently on IRC:
> 
> [02:17] <*******> it will have arbitrary theming, backends/rendering engines, probably arbitrary shapes for windows and widgets, easy new widget creation, immediate mode interface, will be extremely configurable, etc, etc :P

Sounds quite feature-full.  But noticeably lacking is any mention of how messaging and state management will work.  To me that's the real heart of it.  You can always gussy up a GUI with pretty themes later, but if the notification and state management mechanisms aren't solid, then actually coding with it will always be painful.

--bb
November 27, 2007
Bill Baxter wrote:
> The basic idea is that you define rules rather than explicit event handlers, and execution of those rules is triggered by built-in dependency analysis.  The analogy made on the web page is to a spreadsheet.  When you use a spreadsheet you just say how the values in this cell depend on all the others and then it all gets automagically updated for you recursively whenever any dependency changes.

So a largely functional GUI framework. I think that could work decently, though you'd need to define multiple input sources, one of them being the non-GUI portion of your application.

> So I wonder if something like this could be done in D.  Or is there something about the dynamic nature of Python which allows this sort of idea, but makes it unworkable in a static language like D?

You could do this in D or Java or C# or C or assembly, I'm sure.

> Anyway it's a neat idea that seems to me to have potential to take us beyond the same old event-driven paradigm that's been rehashed for years and starts to get quite cumbersome beyond a certain point.

One complex part is ordering event handlers. I have an event that five things listen to, but one handler has to fire before another, which has to fire before a third.

I haven't seen much else cumbersome with it yet, but I'm still young :) What problems have you encountered?

> Another interesting GUI-related lib from Python-land that I have my eye on is Traits from Enthought [2].

I don't see how this would work. Do you register an event handler, essentially, and that is used to determine which GUI components to show?

For me, I want codegen for my GUI stuff, and as little code as possible interacting directly with that generated code as possible. I also want something that makes model/view/presenter easy to use, or at least that lets me use mock objects with minimal fuss.

And I want a dependency injection framework.

> --bb
> 
> Links:
> [1] http://cheeseshop.python.org/pypi/Trellis/0.5b1
> [2] http://code.enthought.com/traits/
November 27, 2007
Lutger wrote:
> Another interesting idea is immediate mode gui. It basically means that no or almost no state is maintained, at least as far as the user is concerned. Instead, the gui is recreated as needed. I've been playing a bit with it and it works nicely, but somehow I had some trouble with more complex gui's.
> 
> Here's a link, the video is worth it imo:
> 
> https://mollyrocket.com/forums/viewtopic.php?t=134


What worries me about immediate mode guis is performance. I suppose they are great for building the gui portion of a game or some really flashy app but I don't see an improvement for typical applications where the gui doesn't change unless until it receives some input from the user.

Just picture a dumb +30 fields form that's using 100% CPU because it is repainting it self every frame.




-- 
Julio César Carrascal Urquijo
http://jcesar.artelogico.com/
November 27, 2007
Lutger wrote:
> Another interesting idea is immediate mode gui. It basically means that no or almost no state is maintained, at least as far as the user is concerned. Instead, the gui is recreated as needed. I've been playing a bit with it and it works nicely, but somehow I had some trouble with more complex gui's.
> 
> Here's a link, the video is worth it imo:
> 
> https://mollyrocket.com/forums/viewtopic.php?t=134

Very interesting.  I watched the first few minutes and read some of the comments on the web page.   Looking forward to checking out the whole video when I have the time.

--bb
« First   ‹ Prev
1 2 3 4