What Features Should A GUI toolkit have?

Thu Mar 5 22:30:40 PST 2015

On 6/03/2015 7:02 p.m., Taylor Hillegeist wrote:
> So I have played with a few GUI libraries with bindings available
> through D. Personally I find that it seems like there is alot of effort
> being put forth on GUI projects.
>
> It is my experience that most project's fail or die, not because of lack
> of effort but lack of specification, many people start projects
> thinking, can i make it do this? how about this? and a project is born!
> but soon interest is lost and the project dies. But specification can
> lead to projects that become useful earlier, more stable, and live
> longer happier lives.
>
> At this point i think the following features are the most useful.
>
> -Ease of setup-
> dub integration is awesome, without it things are more difficult. This
> has very little to do with the actual toolkit.
>
> -Minimal dependencies-
> Personally If i can statically link a toolkit to my GUI and it has zero
> dependencies outside of the OS typically install. I am very happy.
> really the less that can be messed with the better.
>
> best in my opinion: DWT MiniGUI DGUI at least for windows.

Devisualization projects were all designed with this in mind.

> -Rock Solid Stable-
> So when I do the hello world application I resize the window push the
> buttons and do pretty normal things. But on some libraries I get weird
> stuff going on sometimes the window even becomes invisible..... scary.
>
> best in my opinion: GTKD TKD
>
> -GUI EDITOR/BUILDER-
> Good- You can edit a static layout
> Better- you can edit a layout and re-size the window layout responds
> Best- you can edit the actual window in real time without recompile.

+1
Reasonable, as long as the events that is D code doesn't change. And 
even then it could be doable via shared libraries.

> Good- You have a pallet of basic widgets that you can place.
> Better- You have a pallet of basic widgets + custom widgets that you can
> edit.
> Best- You have the above + a database were people can share widgets :)

Yeah no. Would realistically required D code unless you want something 
like lua.

> -Widgets-
> Personally I think that all layout items like HBar should be children of
> widget that way i can make more modular component, but that's just my
> opinion.

+1

> -Data Binding-
> Most of the time I use that data a widget represents and much less often
> the events they produce.

+1

> -Ease of Use-
> Your tookits should work for you... not the other way round.

+1

> -layout-
> I have seen some schemes like Winforms Dock,javaFX HBar, HTML5's
> float/static/absolute/realitive... Idk what seems the most freindly...
> HTML5/css seems the most complex. I have a dream H/VBar +
> align/distribution/wrap options.

My opinion which isn't exactly normal is that layout's are just an 
algorithm on how to size/location of the child elements. Keep them 
separate and configurable. These issues can all be abstracted away.

> I know some of these are RAD things. I don't have an opinion on thread
> safe guis. personally I would like to see a GUI tookit that the
> community said... use X it is just the way to go for most things.

Threading is a big no no with GUI's. Don't even consider it. Well for 
rendering anyway.
Separating out the controls raw data from the drawing is important for 
this. That way other threads can control where widgets ext. are or there 
data without directly drawing.

I'll summarize my views on all of this.
We keep making the same damn mistakes time after time. Especially with 
GUI's.
Stop trying to make GUI toolkits! Seriously just stop.
WE DO NOT HAVE THE INFRASTRUCTURE FOR IT. Yes I know that is yelling but 
it is true. We're still a long way off having proper image manipulation. 
Or even basic OpenGL wrapping functions. DirectX don't even joke.

So what can we do to get to this point? Continue on improving dub. You 
know what doesn't matter? file format for dub. What does matter is 
getting proper live reloading capabilities. Livereload is good and all 
but most of you won't be happy with it.
We also need a strong image toolkit. We still don't have a common color 
definition.

After an image toolkit/color definition has been sorted the next target 
is get extern(Obj-C) working. We need this for OSX.

Now a project like Devisualization.Window can be extended to support 
e.g. displays. Also getting the OSX window code in D instead of Objective-C.

So to recap, image toolkit is number 1 goal right now. Second is to get 
Devisualization.Window similar project extended.

Once this is done, then it is on to e.g. a scenegraph. A good 2d 
scenegraph can be used to represent widget hierarchies. A good 3d one 
can be used in games. Combine them both and you can have 2d overlayed on 
3d for games. Can you say game UI which is not dedicated to games?

We have the ability to create instances of classes at runtime using only 
there names. Dynamic eventing isn't an issue here. Of course if we could 
pair dmd-fe up with a JIT we could do amazing things... Also embedded 
interface files would be rather useful for this.

Now and only now can we consider a GUI toolkit. The scary thing is I 
don't know why I even say all of this. Because by the time we get our 
act together it will be atleast 4-5 years.

TLDR: We think far too big and never actually work with a clear 
strategic path towards a goal in mind.