What Features Should A GUI toolkit have?
Rikki Cattermole via Digitalmars-d
digitalmars-d at puremagic.com
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.
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
> Best- You have the above + a database were people can share widgets :)
Yeah no. Would realistically required D code unless you want something
> 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
> -Data Binding-
> Most of the time I use that data a widget represents and much less often
> the events they produce.
> -Ease of Use-
> Your tookits should work for you... not the other way round.
> 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
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
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
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.
More information about the Digitalmars-d