On Wednesday, 4 March 2015 at 08:05:32 UTC, Kagamin wrote:
> On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:
>> I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented.
>
> See also Harmonia http://www.terrainformatica.com/2014/07/10-years-road-to-sciter/ for an older (now dead) attempt at abstracting a GUI backend.

Unfortunately, Harmonia was implemented only for Windows, and is now abandoned by author, so we have to look for something else.

On Wednesday, 4 March 2015 at 01:46:44 UTC, Rikki Cattermole wrote:
> Also, you can drop Qt almost completely for wanting its window creation functionality.
>
> http://github.com/Devisualization/window
>
> I've got a bunch of other projects, image, model loading, scene graph. Google Material design GUI toolkit but it is a LONG way off.
> I also have started (locally) a new GUI toolkit that uses the Buffer2D context instead of OpenGL.
>
> And yes, Devisualization.Window works on the three big platforms.

Thanks, I will take a look. Are you the author of this project?

On 5/03/2015 9:38 a.m., Aram wrote:
> On Wednesday, 4 March 2015 at 01:46:44 UTC, Rikki Cattermole wrote:
>> Also, you can drop Qt almost completely for wanting its window
>> creation functionality.
>>
>> http://github.com/Devisualization/window
>>
>> I've got a bunch of other projects, image, model loading, scene graph.
>> Google Material design GUI toolkit but it is a LONG way off.
>> I also have started (locally) a new GUI toolkit that uses the Buffer2D
>> context instead of OpenGL.
>>
>> And yes, Devisualization.Window works on the three big platforms.
>
> Thanks, I will take a look. Are you the author of this project?

Yes I am.

On Wed, 04 Mar 2015 14:28:49 +0000, Jonas Drewsen wrote:

> On Tuesday, 3 March 2015 at 23:45:36 UTC, ketmar wrote:
>> On Tue, 03 Mar 2015 20:21:29 +0000, Jonas Drewsen wrote:
>>
>>> I've done a GUI toolkit with CSS support in D for my editor. Should probably put it on github at some point.
>>> 
>>> http://deadcodedev.steamwinter.com/
>>
>> to be honest, it's the most wanted part for me. ;-) i don't need the editor, but i definitely want to take a look at it's gui, 'cause i'm too lazy to finish any of my own libraries (i HATE writing gui libraries! ;-).
> 
> Yeah. Driving people away from the editor they know is a tough quest. Luckily that is not my goal.

btw, your editor looks great, it just doesn't fit into my workflow, where all tools required to use tty. ;-)

> Writing GUI libraries is definitely a lot of work and have a lot of corner cases so I completely agree that it is not the most fun thing to do. On top of that it is hard to do proper automated tests for GUI.

as for me, it's also very hard to decide what scope of GUI library should be. i.e. is this library just for me, so i can expose internals and simply add the comment "don't change this thing" to the code? is this a simple library with limited set of controls, or i want it to be infinitely extendable? or should i hide everything and go with strict "everything is done by sending a message" policy?

i think that this is a known problem for "let's write a library" way of thinking. i.e. when library was not born out of necessity: "hey, i need a GUI for this program! let's write a simplest GUI i can and go on with the main code!"

On Wed, 04 Mar 2015 20:35:15 +0000, Aram wrote:

>> See also Harmonia http://www.terrainformatica.com/2014/07/10-years-road-to-sciter/ for an older (now dead) attempt at abstracting a GUI backend.
> 
> Unfortunately, Harmonia was implemented only for Windows, and is now abandoned by author, so we have to look for something else.

or someone can try to resurrect it. it was very interesting effort, and i'd like to see a "Harmonia resurrected" or something, ported to current D version and with X11 backend.

sadly, i haven't enough time and motivation to do that.

On 2015-03-03 23:29, Jonas Drewsen wrote:
> On Tuesday, 3 March 2015 at 22:16:36 UTC, Freddy wrote:

>> I'm not much of a gui person,but what is the advantage of using QML
>> over D's import
>> statements(http://dlang.org/expression.html#ImportExpression) and CTFE.
>
> No need to recompile (ie. have the source code) the app you are doing
> when you change the QML. This in turn also speeds up design iterations.

I've been thinking of a design that there's a GUI builder tool. When the developer builds the GUI the tool will serialize the GUI to some format, XML, binary or whatever. The application that uses the GUI can load it at runtime for fast development cycles.

As an optimization the tool can serialize the GUI as D code. The application can than, at compile time, load the D code using import expression and mix it in somewhere. In theory, it should be as the developer wrote GUI code by hand.

-- 
/Jacob Carlborg

On 2015-03-05 06:22, ketmar wrote:

> or someone can try to resurrect it. it was very interesting effort, and
> i'd like to see a "Harmonia resurrected" or something, ported to current
> D version and with X11 backend.
>
> sadly, i haven't enough time and motivation to do that.

Everyone is constantly forgetting about OS X :(. No, X11 is not interesting on OS X even though it works.

-- 
/Jacob Carlborg

On Thu, 05 Mar 2015 08:40:36 +0100, Jacob Carlborg wrote:

> Everyone is constantly forgetting about OS X :(.

i'm not forget about it, i'm simply ignoring it, along with windows. strictly speaking, along with anything that is not X11. ;-)

but in this case i'm sure that if there will be win32 and X11 backends, porting to quartz (or OpenGL, or SDL...) will be much easier, as most backend-dependent features will be abstracted away.

On Thursday, 5 March 2015 at 07:39:29 UTC, Jacob Carlborg wrote:
> On 2015-03-03 23:29, Jonas Drewsen wrote:
>> On Tuesday, 3 March 2015 at 22:16:36 UTC, Freddy wrote:
>
>>> I'm not much of a gui person,but what is the advantage of using QML
>>> over D's import
>>> statements(http://dlang.org/expression.html#ImportExpression) and CTFE.
>>
>> No need to recompile (ie. have the source code) the app you are doing
>> when you change the QML. This in turn also speeds up design iterations.
>
> I've been thinking of a design that there's a GUI builder tool. When the developer builds the GUI the tool will serialize the GUI to some format, XML, binary or whatever. The application that uses the GUI can load it at runtime for fast development cycles.
>
> As an optimization the tool can serialize the GUI as D code. The application can than, at compile time, load the D code using import expression and mix it in somewhere. In theory, it should be as the developer wrote GUI code by hand.

This is the approach taken by modern GUI toolkits for native applications, Qt, JavaFX, XAML, Android.

I imagine on Mac OS/iOS NIBs also follow a similar pattern.

--
Paulo

On Thursday, 5 March 2015 at 05:17:44 UTC, ketmar wrote:
> as for me, it's also very hard to decide what scope of GUI library should
> be. i.e. is this library just for me, so i can expose internals and
> simply add the comment "don't change this thing" to the code?

You mean access to the backend primitives? That should be possible. Also can't you have a CUI backend?

> is this a
> simple library with limited set of controls, or i want it to be
> infinitely extendable?

Provide a minimal set of controls and extended one in a separate library. Should be doable, I see no reason to fix the control set.