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.

-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.

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 :)

-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.

-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.

-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.

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.

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.

On Fri, 06 Mar 2015 19:30:40 +1300, Rikki Cattermole wrote:

> Stop trying to make GUI toolkits! Seriously just stop.

+4624!

it should be turned inside out: to be productive we need component framework a-la BlackBox Component Builder. sadly, most people were never worked with *real* component framework, so they keep thinking that "ide + gui builder + compiler is like component framework". no, no, and no. not even close. that loses the main property of component frameworks: you aren't writing program using CF, you are simply extending CF until it can do what you want.

D is one small step away from the goal: all it need is dynamic module loader. i.e. a module that can load other compiled modules with all their dependences, and can unload modules (again removing all unused dependencies). with dynamic loader the way to component framework is open.

but alas: dynamic loader means that D should stop producing that "object files" for linkers. it has to produce something like delphi .dcus (a compiled code, plus all the interface -- it can be titled "rich object file").

writing "gui toolkits" is like randomly throwing bricks, windows, doors and floor panes onto buildint site and hoping that they somehow will arrange themselves into the real house.

On Friday, 6 March 2015 at 06:02:17 UTC, Taylor Hillegeist wrote:
> -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.

For user components, a UserControl is provided https://msdn.microsoft.com/en-us/library/system.windows.forms.usercontrol.aspx it can have layout inside and functionality focused on support for composite user components.

> -layout-
> I have a dream H/VBar + align/distribution/wrap options.

That's how GTK works. Layouts can be provided separately, anchors is the simplest one, boxes is the most flexible.

> I don't have an opinion on thread safe guis.

If you really need it, you can incapsulate thread-safety in a ViewModel (MVVM), while View will remain single-threaded.

On Friday, 6 March 2015 at 07:49:51 UTC, ketmar wrote:
> it should be turned inside out: to be productive we need component
> framework a-la BlackBox Component Builder. sadly, most people were never
> worked with *real* component framework, so they keep thinking that "ide +
> gui builder + compiler is like component framework". no, no, and no. not
> even close. that loses the main property of component frameworks: you
> aren't writing program using CF, you are simply extending CF until it can
> do what you want.

Components are coming to HTML5:

http://jonrimmer.github.io/are-we-componentized-yet/

Google is experimenting with implementing their "Material GUI" in it:

https://www.polymer-project.org/components/paper-elements/demo.html#paper-checkbox

Sure, you can do your own in D, but you probably cannot keep up if this takes off... It would make a lot more sense to focus on efficient synchronization between native D arrays and javascript and utilize what already is there. HTML5 provides ArrayView objects that basically are slices of raw memory.

It could work out nicely.

On Fri, 2015-03-06 at 10:01 +0000, via Digitalmars-d wrote:
> 
[…]
> Components are coming to HTML5:
> 
> […]
> 
> It could work out nicely.
> 

On the other hand for a non-browser UI, it doesn't really make sense!

Personally I cannot see a new D implemented graphics system and GUI system on top of it being anything more than hobby project there is not enough resource or traction with D to compete against Qt. Hate it or really hate it, Qt is currently the leader in Linux, UNIX (inc OSX), Windows agnostic graphics and GUI.

It would be really good if there were resource, especially given the demise of OpenGL and OpenCL in the face of Vulkan, since this would be an opportunity for D to excel. But without serious dosh, I can't see it happening: consider the amount of money spent on JavaFX.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Fri, 06 Mar 2015 10:01:34 +0000, Ola Fosheim Grøstad wrote:

> On Friday, 6 March 2015 at 07:49:51 UTC, ketmar wrote:
>> it should be turned inside out: to be productive we need component
>> framework a-la BlackBox Component Builder. sadly, most people were
>> never worked with *real* component framework, so they keep thinking
>> that "ide +
>> gui builder + compiler is like component framework". no, no, and no.
>> not even close. that loses the main property of component frameworks:
>> you aren't writing program using CF, you are simply extending CF until
>> it can do what you want.
> 
> Components are coming to HTML5:
> 
> http://jonrimmer.github.io/are-we-componentized-yet/

wow, what a shitload of crap! exactly what i mean when i wrote "most people doing it wrong".

> Sure, you can do your own in D, but you probably cannot keep up if this takes off... It would make a lot more sense to focus on efficient synchronization between native D arrays and javascript and utilize what already is there. HTML5 provides ArrayView objects that basically are slices of raw memory.
> 
> It could work out nicely.

but that's crap. it's in no way even near the Component Framework. it's the same old GUI crap, but this time with fancy new name.

On Friday, 6 March 2015 at 10:42:37 UTC, Russel Winder wrote:
> On Fri, 2015-03-06 at 10:01 +0000, via Digitalmars-d wrote:
>> 
> […]
>> Components are coming to HTML5:
>> 
>> […]
>> 
>> It could work out nicely.
>> 
>
> On the other hand for a non-browser UI, it doesn't really make sense!

Not sure what you mean by a "non-browser UI". You need a model, a layout engine, a composition engine and know-how. Competing with browser engines is a lot of work.

It is going to be very hard to compete with reusable UI components implemented in html+javascript, when they have worked out the quirks, due to:

1. ease of development
2. ease of modification
3. volume of UI components
4. styling know-how
5. integration
6. installed base

What you need is a reactive layer that access native data. And webtech provides the basic building blocks for it, thanks to the requirements of asm.js/pnacl.

On Friday, 6 March 2015 at 10:55:34 UTC, ketmar wrote:
> wow, what a shitload of crap! exactly what i mean when i wrote "most
> people doing it wrong".

Describe what is right?

To most developers, doing it right means saving developer time and if possible push "design declarative programming" onto designers.

Which is basically what shadow-dom allows you to do. There are some quirks with styling still, but there is overall progress.

On Fri, 06 Mar 2015 11:34:14 +0000, Ola Fosheim Grøstad wrote:

> On Friday, 6 March 2015 at 10:55:34 UTC, ketmar wrote:
>> wow, what a shitload of crap! exactly what i mean when i wrote "most people doing it wrong".
> 
> Describe what is right?

i did alot of times. Smalltalk, Oberon, BCB. old Symbolics Lisp machines to some extent. ;-) BlueBottle OS.

> To most developers, doing it right means saving developer time and if possible push "design declarative programming" onto designers.

and most of the tools that are trying to help with that fails miserably. i still remember how fast, easy and fun everything was in BlackBox Component Builder. words are nothing, you have to work with it (not play, but work) to feel it's unique power.

> Which is basically what shadow-dom allows you to do. There are some quirks with styling still, but there is overall progress.

it doesn't matter how much they advancing wheelchairs, wheelchairs will never become Lamborghinis.