www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Standard GUI framework inspired by Qt

reply "Aram" <a mailinator.com> writes:
Hi all

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.

In that duscussion many participants agreed that Qt would be a 
good foundation, but had very restrictive license. Things have 
changed since then, and Qt now is available under LGPL, which, to 
my undestanding, makes it suitable for the purpose of standard 
GUI library (please correct me if I am wrong on this). The 
license, of course, may change in the future, preventing us from 
using their updates for our drawing engine. But if we are able to 
start using the engine now, in the future we can maintain the 
updates ourselves.

Now, how I envision the library's design:

The library will be mostly implemented in D, except for drawing 
engine and event loop, which are system-dependent. Those two 
parts will be extracted from Qt into a separate library which 
will be linked to by the rest of framework either statically or 
dynamically. There will be bindings for sending drawing 
instructions to drawing engine, as well as for retrieving system 
and GUI events from event loop.

The system-independent part will mimic architecture of Qt. 
However, for maximum flexibility and customizability, GUI will 
utilize QML+CSS approach, and Qt's layout manager classes will be 
dropped completely. Also there is no need to port classes that 
are available in D, such as collections and strings.


If there is no standard GUI for D yet, and if LGPL license fits 
our purpose, then I am looking for 2-3 Qt experts to join me and 
build the framework.

Thanks,
Aram
Mar 03 2015
next sibling parent "Taylor Hillegeist" <taylorh140 gmail.com> writes:
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a 
 good foundation, but had very restrictive license. Things have 
 changed since then, and Qt now is available under LGPL, which, 
 to my undestanding, makes it suitable for the purpose of 
 standard GUI library (please correct me if I am wrong on this). 
 The license, of course, may change in the future, preventing us 
 from using their updates for our drawing engine. But if we are 
 able to start using the engine now, in the future we can 
 maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for drawing 
 engine and event loop, which are system-dependent. Those two 
 parts will be extracted from Qt into a separate library which 
 will be linked to by the rest of framework either statically or 
 dynamically. There will be bindings for sending drawing 
 instructions to drawing engine, as well as for retrieving 
 system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. 
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


 If there is no standard GUI for D yet, and if LGPL license fits 
 our purpose, then I am looking for 2-3 Qt experts to join me 
 and build the framework.

 Thanks,
 Aram


So I don't speak for the community, but I like the idea of having 
a gui abstracting front end that targets backends, like Qt or GTK 
or Winforms. I know some people probably don't care as much about 
dependencies as me. But for me its always best to target a 
platforms native toolkit, I think it looks better. We should do a 
poll or something.
Mar 03 2015
prev sibling next sibling parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all
 ...
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


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/

No QML-like thing because I feel that belongs in code. For now 
anyway.

/Jonas
Mar 03 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
=20
 http://deadcodedev.steamwinter.com/


to be honest, it's the most wanted part for me. ;-) i don't need the=20
editor, but i definitely want to take a look at it's gui, 'cause i'm too=20
lazy to finish any of my own libraries (i HATE writing gui libraries! ;-).=
Mar 03 2015
parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
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.

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.
Mar 04 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
=20
 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! ;-).


=20
 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=20
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=20
be. i.e. is this library just for me, so i can expose internals and=20
simply add the comment "don't change this thing" to the code? is this a=20
simple library with limited set of controls, or i want it to be=20
infinitely extendable? or should i hide everything and go with strict=20
"everything is done by sending a message" policy?

i think that this is a known problem for "let's write a library" way of=20
thinking. i.e. when library was not born out of necessity: "hey, i need a=20
GUI for this program! let's write a simplest GUI i can and go on with the=20
main code!"=
Mar 04 2015
parent reply "Kagamin" <spam here.lot> writes:
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.
Mar 05 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 05 Mar 2015 08:16:37 +0000, Kagamin wrote:


 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?


=20
 You mean access to the backend primitives?


nope. i mean access to widget object's internals.


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


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


the reason is that with fixed set i can greatly simplify library code.=
Mar 05 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 5 March 2015 at 11:06:18 UTC, ketmar wrote:

 On Thu, 05 Mar 2015 08:16:37 +0000, Kagamin wrote:


 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?


 nope. i mean access to widget object's internals.


The widget object should have only the backend widget handle as 
internal. Well, and maybe signal storage.


 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.


 the reason is that with fixed set i can greatly simplify 
 library code.


Winforms is simple and absolutely agnostic about controls.
Mar 05 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 05 Mar 2015 12:02:20 +0000, Kagamin wrote:


 The widget object should have only the backend widget handle as
 internal. Well, and maybe signal storage.


oh, really? so no deep widget ierarchies, no way to position the widget=20
(as we doesn't store it's coordinates), no way to... no way to define=20
anything. that's will be great GUI!

by the way. what is "backend widget handle" for OpenGL, for example? ah,=20
i see, your idea of "backend" is that backend implements the whole widget=20
system. it's cool.



 Winforms is simple and absolutely agnostic about controls.


winforms sux. dixi.=
Mar 05 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 5 March 2015 at 15:01:20 UTC, ketmar wrote:

 oh, really? so no deep widget ierarchies, no way to position 
 the widget
 (as we doesn't store it's coordinates), no way to... no way to 
 define
 anything. that's will be great GUI!


To position a widget you invoke a backend function on a widget 
handle with desired coordinates.


 by the way. what is "backend widget handle" for OpenGL, for 
 example? ah,
 i see, your idea of "backend" is that backend implements the 
 whole widget
 system.


Yes, the point is to make frontend agnostic about backend 
implementation details. If you want to write entire widget system 
from scratch, like FLTK, that goes to a backend.
Mar 06 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 08:09:15 +0000, Kagamin wrote:


 On Thursday, 5 March 2015 at 15:01:20 UTC, ketmar wrote:

 oh, really? so no deep widget ierarchies, no way to position the widget
 (as we doesn't store it's coordinates), no way to... no way to define
 anything. that's will be great GUI!


=20
 To position a widget you invoke a backend function on a widget handle
 with desired coordinates.


smells like windows.


 by the way. what is "backend widget handle" for OpenGL, for example?
 ah,
 i see, your idea of "backend" is that backend implements the whole
 widget system.


=20
 Yes, the point is to make frontend agnostic about backend implementation
 details. If you want to write entire widget system from scratch, like
 FLTK, that goes to a backend.


so you proposing to throw frontend away, as the only thing that "frontend"=20
keeps is a some handle, that's all. and what the sense of such "frontend"?

besides, your arch is not portable at all. i.e. to port it to another=20
graphic system author has to rewrite the whole thing (as 99% of code is=20
in "backend", and have to be rewritten). so it's easier to drop all that=20
mess and just write direct X11 calls. that's exactly what you are=20
proposing: a single "backend" handle and alot of "frontend" functions=20
that manipulates that handle.=
Mar 06 2015
parent "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 09:35:58 UTC, ketmar wrote:

 To position a widget you invoke a backend function on a widget 
 handle
 with desired coordinates.


 smells like windows.


To some extent, any GUI smells like windows. A widget, as long as 
it exists and is visible, has a size and position, it's basics.


 so it's easier to drop all that
 mess and just write direct X11 calls.


If you want to use platform GUI directly, that's definitely 
possible, nobody prohibits that.
Mar 06 2015
prev sibling next sibling parent reply "Freddy" <Hexagonalstar64 gmail.com> writes:
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a 
 good foundation, but had very restrictive license. Things have 
 changed since then, and Qt now is available under LGPL, which, 
 to my undestanding, makes it suitable for the purpose of 
 standard GUI library (please correct me if I am wrong on this). 
 The license, of course, may change in the future, preventing us 
 from using their updates for our drawing engine. But if we are 
 able to start using the engine now, in the future we can 
 maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for drawing 
 engine and event loop, which are system-dependent. Those two 
 parts will be extracted from Qt into a separate library which 
 will be linked to by the rest of framework either statically or 
 dynamically. There will be bindings for sending drawing 
 instructions to drawing engine, as well as for retrieving 
 system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. 
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


 If there is no standard GUI for D yet, and if LGPL license fits 
 our purpose, then I am looking for 2-3 Qt experts to join me 
 and build the framework.

 Thanks,
 Aram


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.
Mar 03 2015
next sibling parent "Freddy" <Hexagonalstar64 gmail.com> writes:
On Tuesday, 3 March 2015 at 22:16:36 UTC, Freddy wrote:

 On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a 
 good foundation, but had very restrictive license. Things have 
 changed since then, and Qt now is available under LGPL, which, 
 to my undestanding, makes it suitable for the purpose of 
 standard GUI library (please correct me if I am wrong on 
 this). The license, of course, may change in the future, 
 preventing us from using their updates for our drawing engine. 
 But if we are able to start using the engine now, in the 
 future we can maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for 
 drawing engine and event loop, which are system-dependent. 
 Those two parts will be extracted from Qt into a separate 
 library which will be linked to by the rest of framework 
 either statically or dynamically. There will be bindings for 
 sending drawing instructions to drawing engine, as well as for 
 retrieving system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. 
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


 If there is no standard GUI for D yet, and if LGPL license 
 fits our purpose, then I am looking for 2-3 Qt experts to join 
 me and build the framework.

 Thanks,
 Aram


 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.


*import expression.
Mar 03 2015
prev sibling parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
On Tuesday, 3 March 2015 at 22:16:36 UTC, Freddy wrote:

 On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a 
 good foundation, but had very restrictive license. Things have 
 changed since then, and Qt now is available under LGPL, which, 
 to my undestanding, makes it suitable for the purpose of 
 standard GUI library (please correct me if I am wrong on 
 this). The license, of course, may change in the future, 
 preventing us from using their updates for our drawing engine. 
 But if we are able to start using the engine now, in the 
 future we can maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for 
 drawing engine and event loop, which are system-dependent. 
 Those two parts will be extracted from Qt into a separate 
 library which will be linked to by the rest of framework 
 either statically or dynamically. There will be bindings for 
 sending drawing instructions to drawing engine, as well as for 
 retrieving system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. 
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


 If there is no standard GUI for D yet, and if LGPL license 
 fits our purpose, then I am looking for 2-3 Qt experts to join 
 me and build the framework.

 Thanks,
 Aram


 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.
Mar 03 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Mar 04 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Mar 05 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-03-05 09:05, Paulo Pinto wrote:


 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.


Not as far as I know. It can only load the nib at runtime, at least 
officially.

The only GUI builder that works like this that I have seen is Eclipse 
WindowBuilder for Java. It operates on the Java AST directly using JDT.

-- 
/Jacob Carlborg
Mar 06 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 4/03/2015 7:43 a.m., Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a good
 foundation, but had very restrictive license. Things have changed since
 then, and Qt now is available under LGPL, which, to my undestanding,
 makes it suitable for the purpose of standard GUI library (please
 correct me if I am wrong on this). The license, of course, may change in
 the future, preventing us from using their updates for our drawing
 engine. But if we are able to start using the engine now, in the future
 we can maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for drawing engine
 and event loop, which are system-dependent. Those two parts will be
 extracted from Qt into a separate library which will be linked to by the
 rest of framework either statically or dynamically. There will be
 bindings for sending drawing instructions to drawing engine, as well as
 for retrieving system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. However, for
 maximum flexibility and customizability, GUI will utilize QML+CSS
 approach, and Qt's layout manager classes will be dropped completely.
 Also there is no need to port classes that are available in D, such as
 collections and strings.


 If there is no standard GUI for D yet, and if LGPL license fits our
 purpose, then I am looking for 2-3 Qt experts to join me and build the
 framework.

 Thanks,
 Aram


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.
Mar 03 2015
parent reply "Aram" <a mailinator.com> writes:
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?
Mar 04 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Mar 04 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
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.
Mar 04 2015
parent reply "Aram" <a mailinator.com> writes:
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.
Mar 04 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.


=20
 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=20
i'd like to see a "Harmonia resurrected" or something, ported to current=20
D version and with X11 backend.

sadly, i haven't enough time and motivation to do that.=
Mar 04 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Mar 04 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.=20
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,=20
porting to quartz (or OpenGL, or SDL...) will be much easier, as most=20
backend-dependent features will be abstracted away.=
Mar 04 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 5/03/2015 8:58 p.m., ketmar wrote:

 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.


Ugh X11 on OSX isn't as easy as it sounds. Especially for OpenGL usage.

I know, I had to modify Derelict-GL3 to do it...

Either way just writing the damn window implementation in obj-c is far 
easier.
Mar 05 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 00:20:25 +1300, Rikki Cattermole wrote:


 On 5/03/2015 8:58 p.m., ketmar wrote:

 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.


=20
 Ugh X11 on OSX isn't as easy as it sounds. Especially for OpenGL usage.
=20
 I know, I had to modify Derelict-GL3 to do it...
=20
 Either way just writing the damn window implementation in obj-c is far
 easier.


to be honest, i prefer to use X11 even for windows. if i need to port=20
some of my GUI code to windows... well, working X11 server is=20
prerequisite. cygwin's, for example. ;-)=
Mar 05 2015
prev sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Thursday, 5 March 2015 at 11:20:28 UTC, Rikki Cattermole wrote:

 On 5/03/2015 8:58 p.m., ketmar wrote:

 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.


 Ugh X11 on OSX isn't as easy as it sounds. Especially for 
 OpenGL usage.

 I know, I had to modify Derelict-GL3 to do it...

 Either way just writing the damn window implementation in obj-c 
 is far easier.


I don't think a GUI library should ever be using X11 on OSX. Not 
only does it have issues like forcing you to download XQuartz 
manually and not being officially supported by Apple anymore, but 
more importantly, it doesn't support high DPI. High DPI support 
is crucial for any new GUI libraries, as more and more laptops 
and monitors are switching to high res screens (and Macs in 
particular are very quickly switching towards a retina focus).
Mar 05 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-03-05 08:58, ketmar wrote:

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


Fair enough :). I still don't like it though :(

-- 
/Jacob Carlborg
Mar 06 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 17:07:55 +0100, Jacob Carlborg wrote:


 On 2015-03-05 08:58, ketmar wrote:

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


=20
 Fair enough :). I still don't like it though :(


i'm not a real fan of X11 too -- it's showing it's roots already. but i=20
like it's core simplicity (oh, no, full xorg is a beast, especially with=20
crap like xrender and dropping XIE!). and i really like network=20
transparency (yep, it works! ;-).=
Mar 06 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 March 2015 at 17:03:51 UTC, ketmar wrote:

 but i
 like it's core simplicity (oh, no, full xorg is a beast, 
 especially with


Opening a simple window with nothing on it in a portable and 
compliant manner using xlib is at least 800 lines of code... 
Simple!
Mar 06 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 18:55:31 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Friday, 6 March 2015 at 17:03:51 UTC, ketmar wrote:

 but i like it's core simplicity (oh, no, full xorg is a beast,
 especially with


=20
 Opening a simple window with nothing on it in a portable and compliant
 manner using xlib is at least 800 lines of code...
 Simple!


ahem...

  //import iv.x11.X, iv.x11.Xlib;
  import iv.x11;
  import iv.writer;


  int main () {
    Display *dpy =3D XOpenDisplay();
    if (!dpy) {
      errwriteln("FATAL: XOpenDisplay failed!");
      return 1;
    }

    int screen =3D DefaultScreen(dpy);

    Window window =3D XCreateSimpleWindow(
      dpy,
      DefaultRootWindow(dpy),  //parent window
      0, 0, 323, 200, 0,           //x, y, width, height, border_width
      BlackPixel(dpy, screen), //border_color
      WhitePixel(dpy,screen)   //back_color
    );

    writefln!"dpy=3D%s; wid=3D%s"(dpy, window);

    XStoreName(dpy, window, "Example window");
    XSelectInput(dpy, window, ExposureMask);
    XMapWindow(dpy, window);

    Atom wmDeleteMessage =3D XInternAtom(dpy, "WM_DELETE_WINDOW", False);
    XSetWMProtocols(dpy, window, &wmDeleteMessage, 1);

    GC gc =3D DefaultGC(dpy, screen);

    bool running =3D true;
    while (running) {
      XEvent event;
      KeySym keySym;
      while (running && XPending(dpy)) {
        XNextEvent(dpy, &event);
        switch (event.type) {
          case ClientMessage:
            if (cast(Atom)event.xclient.data.l[0] =3D=3D wmDeleteMessage) {
              writeln("delete message");
              running =3D false;
            }
            break;
          case Expose:
            auto ee =3D cast(XExposeEvent*)&event;
            writefln!"expose event(dpy=3D%s, wid=3D%s); serial=3D%s; send=
=3D%s; x=3D
%s; y=3D%s; count=3D%s"
               (ee.display, ee.window, ee.serial, ee.send_event, ee.x,=20
ee.y, ee.count);
            XDrawString(dpy, cast(Drawable)window, gc, 10, 16, "Hello=20
world!", 12);
            break;
          default:
        }
      }
    }

    XUnmapWindow(dpy, window);
    XDestroyWindow(dpy, window);
    XCloseDisplay(dpy);

    return 0;
  }
=
Mar 07 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 7 March 2015 at 09:27:42 UTC, ketmar wrote:

 On Fri, 06 Mar 2015 18:55:31 +0000, Ola Fosheim Grøstad wrote:


 On Friday, 6 March 2015 at 17:03:51 UTC, ketmar wrote:

 but i like it's core simplicity (oh, no, full xorg is a beast,
 especially with


 
 Opening a simple window with nothing on it in a portable and 
 compliant
 manner using xlib is at least 800 lines of code...
 Simple!


 ahem...


You are cheating. You first have to find the optimal visual using 
XGetVisualInfo. You need to create an appropriate colormap. You 
need to set WM hints using XSetWMProperties. And so on...
Mar 07 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 07 Mar 2015 16:30:27 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Saturday, 7 March 2015 at 09:27:42 UTC, ketmar wrote:

 On Fri, 06 Mar 2015 18:55:31 +0000, Ola Fosheim Gr=C3=83=C2=B8stad wrote=




:

 On Friday, 6 March 2015 at 17:03:51 UTC, ketmar wrote:

 but i like it's core simplicity (oh, no, full xorg is a beast,
 especially with


=20
 Opening a simple window with nothing on it in a portable and compliant
 manner using xlib is at least 800 lines of code...
 Simple!


 ahem...


=20
 You are cheating.


in no way. i even did more than you asked, as you told to "open a simple=20
window with nothing on it", and i wrote text there.


 You first have to find the optimal visual using XGetVisualInfo.
 You need to create an appropriate colormap.


for what reason? it's always guaranteed to have at least black and white=20
colors.


 You need to set WM hints using XSetWMProperties.


i don't need 'em. my Fluxbox is happy as it is (and much other WMs too).


 And so on...


there is nothing more. simple as it is.=
Mar 07 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 7 March 2015 at 17:56:21 UTC, ketmar wrote:

 there is nothing more. simple as it is.


You are cheating. :P

And there is nothing simple about X11 if you follow the protocols 
and want to do real work, it is outdated by a wide margin, and so 
is the use scenario: running low level UI events/graphic commands 
over ethernet replacing TTYs with the graphical equivalent... It 
was outdated 25 years ago!

X11 is the Frankenstein of  UI and has probably made a big dent 
in Linux' ability to reach a more casual audience... It belongs 
in a museum...
Mar 07 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 07 Mar 2015 18:10:36 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Saturday, 7 March 2015 at 17:56:21 UTC, ketmar wrote:

 there is nothing more. simple as it is.


=20
 You are cheating. :P


in no way. ;-)


 And there is nothing simple about X11 if you follow the protocols and
 want to do real work


i wrote some GUI toolkits for X11 in C, and i must say that X11 is simple.


 it is outdated by a wide margin


yes, we need X12. but not from packard, he is insanely dumb.


 and so is the use
 scenario: running low level UI events/graphic commands over ethernet
 replacing TTYs with the graphical equivalent... It was outdated 25 years
 ago!


it wasn't outdated. and i must say that i'm using this feature on dayly=20
basis. by the way, X11 is not restricted to do only "low level" things.

if only that shitheads didn't kill XIE...


 X11 is the Frankenstein of  UI


X11 was never an UI system. it's WINDOW system. and window is just a=20
rectangular area on a display. that's it.


 and has probably made a big dent in
 Linux' ability to reach a more casual audience...


ah, one of the things of which i can't care less. ;-)


 It belongs in a museum...


there is no alternative. i'd be happy to get one, but there simply isn't.=
Mar 07 2015
prev sibling next sibling parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a 
 good foundation, but had very restrictive license. Things have 
 changed since then, and Qt now is available under LGPL, which, 
 to my undestanding, makes it suitable for the purpose of 
 standard GUI library (please correct me if I am wrong on this). 
 The license, of course, may change in the future, preventing us 
 from using their updates for our drawing engine. But if we are 
 able to start using the engine now, in the future we can 
 maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for drawing 
 engine and event loop, which are system-dependent. Those two 
 parts will be extracted from Qt into a separate library which 
 will be linked to by the rest of framework either statically or 
 dynamically. There will be bindings for sending drawing 
 instructions to drawing engine, as well as for retrieving 
 system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. 
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


 If there is no standard GUI for D yet, and if LGPL license fits 
 our purpose, then I am looking for 2-3 Qt experts to join me 
 and build the framework.

 Thanks,
 Aram


Probably DlangUI fits your requirements.
https://github.com/buggins/dlangui

It's written in D, so can be easy extended.
Cross platform - backend part is separated, and new platforms 
support can be added. So far, win32 and SDL2 backends are 
implemented. There is as well X (XCB) backend, but now it's 
abandoned.

Look and feel can be customized using themes and styles.
Mar 05 2015
parent reply "Aram" <a mailinator.com> writes:
On Thursday, 5 March 2015 at 13:38:58 UTC, Vadim Lopatin wrote:

 Probably DlangUI fits your requirements.
 https://github.com/buggins/dlangui

 It's written in D, so can be easy extended.
 Cross platform - backend part is separated, and new platforms 
 support can be added. So far, win32 and SDL2 backends are 
 implemented. There is as well X (XCB) backend, but now it's 
 abandoned.

 Look and feel can be customized using themes and styles.


Unfortunately, if it doesn't cover all major PC platforms, it 
doesn't suit me (Mac OS is not supported). I would like to have 
all backends working on all platforms, as I lack knowledge to 
implement my own backends for X and Mac OS.
Mar 05 2015
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Thursday, 5 March 2015 at 15:09:55 UTC, Aram wrote:

 On Thursday, 5 March 2015 at 13:38:58 UTC, Vadim Lopatin wrote:

 Probably DlangUI fits your requirements.
 https://github.com/buggins/dlangui

 It's written in D, so can be easy extended.
 Cross platform - backend part is separated, and new platforms 
 support can be added. So far, win32 and SDL2 backends are 
 implemented. There is as well X (XCB) backend, but now it's 
 abandoned.

 Look and feel can be customized using themes and styles.


 Unfortunately, if it doesn't cover all major PC platforms, it 
 doesn't suit me (Mac OS is not supported). I would like to have 
 all backends working on all platforms, as I lack knowledge to 
 implement my own backends for X and Mac OS.


Why not? SLD2 backend works ok on Mac (as well as on linux and 
windows).
But on mac native menus are not supported. Instead, menu is show 
at the top of window.
Mar 05 2015
parent reply "Aram" <a mailinator.com> writes:
On Thursday, 5 March 2015 at 18:42:56 UTC, Vadim Lopatin wrote:

 On Thursday, 5 March 2015 at 15:09:55 UTC, Aram wrote:

 Unfortunately, if it doesn't cover all major PC platforms, it 
 doesn't suit me (Mac OS is not supported). I would like to 
 have all backends working on all platforms, as I lack 
 knowledge to implement my own backends for X and Mac OS.


 Why not? SLD2 backend works ok on Mac (as well as on linux and 
 windows).
 But on mac native menus are not supported. Instead, menu is 
 show at the top of window.


Ok, I will take a look at it. By the way, what is SDL2 in brief?
Mar 06 2015
next sibling parent "Namespace" <rswhite4 gmail.com> writes:
On Friday, 6 March 2015 at 19:30:14 UTC, Aram wrote:

 On Thursday, 5 March 2015 at 18:42:56 UTC, Vadim Lopatin wrote:

 On Thursday, 5 March 2015 at 15:09:55 UTC, Aram wrote:

 Unfortunately, if it doesn't cover all major PC platforms, it 
 doesn't suit me (Mac OS is not supported). I would like to 
 have all backends working on all platforms, as I lack 
 knowledge to implement my own backends for X and Mac OS.


 Why not? SLD2 backend works ok on Mac (as well as on linux and 
 windows).
 But on mac native menus are not supported. Instead, menu is 
 show at the top of window.


 Ok, I will take a look at it. By the way, what is SDL2 in brief?


https://www.libsdl.org/index.php
Mar 06 2015
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 6 March 2015 at 19:30:14 UTC, Aram wrote:

 By the way, what is SDL2 in brief?


"Simple DirectMedia Layer is a cross-platform development library 
designed to provide low level access to audio, keyboard, mouse, 
joystick, and graphics hardware via OpenGL and Direct3D."

http://www.libsdl.org/

-Wyatt
Mar 06 2015
parent reply "karl" <ultrano hotmail.com> writes:
Please don't use SDL2 and such as basis, or OpenGL with 
glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a 
GL driver dev (userspace) for a smaller company, and I see too 
much gore in popular software like that (gnome3 is the 
most-horrific). A fully-featured GUI with GL needs only a thin 
wrapper for glXGetProcAddress, GL context creation, BitBlt-like 
things and font-glyph cache (or better yet, signed-distance-field 
text rendering). Something like this:

Base (sans clipping, I haven't ported it from asm yet):
https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw

SDF text:
https://www.mapbox.com/blog/text-signed-distance-fields/

Also, GL should be optional, just like with Qt; it introduces 
noticeable lag of 16 to 48ms while being a resource hog 
unnecessary for most apps. I could help with implementing the 
abstraction layer and create a software blitter (I was 
professionally doing such stuff before, for GUI toolkits and 
stuff; but then again this stuff is trivial).

A 32-bit backing-store is always vital (DDB+GDI dibsection, GL 
texture and such). Qt has it (and implemented really-well) and 
that's the first pixel-related thing we should implement. BGRA8 
will be the best format (blue in LSB).
A 9-cell blit will also be vital functionality.
Mar 09 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 10 Mar 2015 01:25:03 +0000, karl wrote:


 Please don't use SDL2 and such as basis


what is wrong with SDL2? it doesn't use `glReadPixels()`, afair. and if=20
it's doing something very wrong, and you know how to made it better,=20
would you please fill bugreport?=
Mar 09 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote:

 Also, GL should be optional, just like with Qt; it introduces 
 noticeable lag of 16 to 48ms while being a resource hog 
 unnecessary for most apps. I could help with implementing the 
 abstraction layer and create a software blitter (I was 
 professionally doing such stuff before, for GUI toolkits and 
 stuff; but then again this stuff is trivial).


16 ms is not noticeable lag for any reasonable application.

One has to limit the design to something that can be completed in 
reasonable time and that offers something that existing solutions 
do not. So there is a need to fix the minimum requirements and 
target that. Either the minimum is a regular screen buffer or it 
is capable shader based hardware.
Mar 10 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 10 Mar 2015 10:32:09 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote:

 Also, GL should be optional, just like with Qt; it introduces
 noticeable lag of 16 to 48ms while being a resource hog unnecessary for
 most apps. I could help with implementing the abstraction layer and
 create a software blitter (I was professionally doing such stuff
 before, for GUI toolkits and stuff; but then again this stuff is
 trivial).


=20
 16 ms is not noticeable lag for any reasonable application.


besides, i can hardly imagine where that comes from, as videogames seems=20
to be able to push hundreds of frames per second. it seems that "16 ms=20
lag" here comes from "synchronise screen updates with vblank" (1000/16 ~=3D=
=20
60, which is common refresh rate for LCDs). and this synchronisation is=20
purely optional on most hardware.

besides, why anyone may want to update the screen faster than monitor=20
redraws it?=
Mar 10 2015
parent reply "karl" <ultrano hotmail.com> writes:
SDL2: Chooses the deprecated color-mode in GLX; prevents you from 
creating a core context; keeps the baseline as if everyone has 
only hardware from 2001 or earlier that somehow still works; 
while preventing batching at every single operation. glBegin, 
glRectf, glReadPixels+manually_flip_y+convert(). It's not the 
thing you want for rendering 16k+ glyphs and items onscreen in a 
GUI.

16-48ms : drag/resize something in an existing GL GUI. Or even 
better, disable your mouse hw accel (it's an overlay thing, right 
before the RAMDAC) (but still GL-accelerated by your compositor 
of choice). You'll see what I mean. Also, latency != rate.
Mar 10 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 10 Mar 2015 20:01:01 +0000, karl wrote:


 SDL2: Chooses the deprecated color-mode in GLX; prevents you from
 creating a core context; keeps the baseline as if everyone has only
 hardware from 2001 or earlier that somehow still works; while preventing
 batching at every single operation. glBegin, glRectf,
 glReadPixels+manually_flip_y+convert(). It's not the thing you want for
 rendering 16k+ glyphs and items onscreen in a GUI.


somehow it works for me.


 16-48ms : drag/resize something in an existing GL GUI.


no prob. no noticable lag too. stunning rock-solid 85 FPS, including=20
active game scene on the background. if i'm doing something wrong in my=20
code, then ok, i can live with it as long as it works.


 by your compositor


ah, i just found your problem! i have no any stinkin' "compositor" on my=20
box.=
Mar 10 2015
parent reply "karl" <ultrano hotmail.com> writes:
Good for you then. Sucks to be _everyone_ else using this planned 
toolkit which is riding on the GL-is-vital-for GUI hypetrain, eh?
Mar 10 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 10 Mar 2015 20:24:03 +0000, karl wrote:


 Good for you then. Sucks to be _everyone_ else using this planned
 toolkit which is riding on the GL-is-vital-for GUI hypetrain, eh?


never had *any* problems with GL toolkits.

ah, well, there was a 20 minutes when i had problems: when i decided to=20
jump on that "desktop with compositor" train. and then i dropped it for=20
good.=
Mar 10 2015
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 10 March 2015 at 20:24:04 UTC, karl wrote:

 Good for you then. Sucks to be _everyone_ else using this 
 planned toolkit which is riding on the GL-is-vital-for GUI 
 hypetrain, eh?


Google just dropped X11 from ChromeOS and replaced it with 
EGL/OpenGL.

http://www.phoronix.com/scan.php?page=news_item&px=Chrome-OS-Freon-Graphics
Mar 10 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 March 2015 at 21:17:02 UTC, Paulo Pinto wrote:

 On Tuesday, 10 March 2015 at 20:24:04 UTC, karl wrote:

 Good for you then. Sucks to be _everyone_ else using this 
 planned toolkit which is riding on the GL-is-vital-for GUI 
 hypetrain, eh?


 Google just dropped X11 from ChromeOS and replaced it with 
 EGL/OpenGL.

 http://www.phoronix.com/scan.php?page=news_item&px=Chrome-OS-Freon-Graphics


It says KMS/DRM and OpenGL for 3D, though. Probably because of 
battery life?
Mar 10 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 10 Mar 2015 21:17:01 +0000, Paulo Pinto wrote:


 Google just dropped X11 from ChromeOS and replaced it with EGL/OpenGL.


that's 'cause they don't need the whole power of X11. most of the tasks=20
there are done by html rendering engine (and done badly, 'cause using=20
HTML for GUIs sux), so they throwed X11 away. right move for such=20
crippled OS.=
Mar 10 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 March 2015 at 20:24:04 UTC, karl wrote:

 Good for you then. Sucks to be _everyone_ else using this 
 planned toolkit which is riding on the GL-is-vital-for GUI 
 hypetrain, eh?


You are the one that suggested distance fields ;-)... Which
actually is what I want to, but not only for fonts. :]
Mar 10 2015
prev sibling next sibling parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 10/03/2015 02:25, karl a écrit :

 Please don't use SDL2 and such as basis, or OpenGL with
 glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL
 driver dev (userspace) for a smaller company, and I see too much gore in
 popular software like that (gnome3 is the most-horrific). A
 fully-featured GUI with GL needs only a thin wrapper for
 glXGetProcAddress, GL context creation, BitBlt-like things and
 font-glyph cache (or better yet, signed-distance-field text rendering).
 Something like this:

 Base (sans clipping, I haven't ported it from asm yet):
 https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw

 SDF text:
 https://www.mapbox.com/blog/text-signed-distance-fields/

 Also, GL should be optional, just like with Qt; it introduces noticeable
 lag of 16 to 48ms while being a resource hog unnecessary for most apps.
 I could help with implementing the abstraction layer and create a
 software blitter (I was professionally doing such stuff before, for GUI
 toolkits and stuff; but then again this stuff is trivial).

 A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture
 and such). Qt has it (and implemented really-well) and that's the first
 pixel-related thing we should implement. BGRA8 will be the best format
 (blue in LSB).
 A 9-cell blit will also be vital functionality.


That the way we choose with DQuick. I use SDL2 under linux only cause I 
was unable to set up a window with xcb. Under Windows the window is 
created by native win32 functions.

For glyph I use fontconfig + freetype and I generate atlases,...

I started a DirectX renderer, but it doesn't work for the moment. So 
pluggin a software renderer would be possible too.

DQuick is just like QtQuick, a simple render coupled to a language that 
support property bindings, if you want more advanced GUI components like 
widgets the user have to create them based on primitives (images, border 
images,...).

But just like Qt do, advanced components can be added after to the 
library as an extension (QtQuick.Controls).

A such GUI library is in theory simpler to do, cause there is no tricky 
things to implement in it to follow native UI of platforms,...
Mar 11 2015
parent reply "Aram" <a mailinator.com> writes:
On Wednesday, 11 March 2015 at 08:22:30 UTC, Xavier Bigand wrote:

 DQuick is just like QtQuick, a simple render coupled to a 
 language that support property bindings, if you want more 
 advanced GUI components like widgets the user have to create 
 them based on primitives (images, border images,...).

 But just like Qt do, advanced components can be added after to 
 the library as an extension (QtQuick.Controls).

 A such GUI library is in theory simpler to do, cause there is 
 no tricky things to implement in it to follow native UI of 
 platforms,...


How can I take a look at DQuik? Is it in working state?
Mar 13 2015
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 13/03/2015 20:38, Aram a écrit :

 On Wednesday, 11 March 2015 at 08:22:30 UTC, Xavier Bigand wrote:

 DQuick is just like QtQuick, a simple render coupled to a language
 that support property bindings, if you want more advanced GUI
 components like widgets the user have to create them based on
 primitives (images, border images,...).

 But just like Qt do, advanced components can be added after to the
 library as an extension (QtQuick.Controls).

 A such GUI library is in theory simpler to do, cause there is no
 tricky things to implement in it to follow native UI of platforms,...


 How can I take a look at DQuik? Is it in working state?


It's on github :
https://github.com/D-Quick/DQuick

We have some tests working, but it's not enough to be usable on a real 
application.

The "DML engine" is almost finished. This night we worked on the file 
reloading. This will allow direct update of GUI when modifying lua files 
without loosing states.

Once the "DML engine" polished, we'll progress and the render part and 
event system. For the moment the mouse input aren't propagate correctly 
in the hierarchy,...

But we hope finding more time to work on it this year.
Mar 14 2015
prev sibling parent reply "Piotrek" <no_data no_data.pl> writes:
On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote:

 Please don't use SDL2 and such as basis, or OpenGL with 
 glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm 
 a GL driver dev (userspace) for a smaller company, and I see 
 too much gore in popular software like that (gnome3 is the 
 most-horrific). A fully-featured GUI with GL needs only a thin 
 wrapper for glXGetProcAddress, GL context creation, BitBlt-like 
 things and font-glyph cache (or better yet, 
 signed-distance-field text rendering). Something like this:

 Base (sans clipping, I haven't ported it from asm yet):
 https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw

 SDF text:
 https://www.mapbox.com/blog/text-signed-distance-fields/

 Also, GL should be optional, just like with Qt; it introduces 
 noticeable lag of 16 to 48ms while being a resource hog 
 unnecessary for most apps. I could help with implementing the 
 abstraction layer and create a software blitter (I was 
 professionally doing such stuff before, for GUI toolkits and 
 stuff; but then again this stuff is trivial).

 A 32-bit backing-store is always vital (DDB+GDI dibsection, GL 
 texture and such). Qt has it (and implemented really-well) and 
 that's the first pixel-related thing we should implement. BGRA8 
 will be the best format (blue in LSB).
 A 9-cell blit will also be vital functionality.


 karl

Can you check the proposal of the new color module by Manu?
https://github.com/D-Programming-Language/phobos/pull/2845

Do you see any issues there?

Piotrek
Mar 12 2015
parent reply "karl" <ultrano hotmail.com> writes:
I'm unsure of the "gamma" space, Adobe should be enough to cover 
things (the curve is practically identical). Still, they are 
different at 0xA7 and 0xBE, so maybe useful for some files. GPUs 
and every non-specialized monitor only do sRGB<->linear.
So, all's good with that pull request, just "gamma" might be 
useless and confusing.
Mar 12 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
Gamma is a common color-tweaking setting available in some games. 
Don't know why, but it's done that way.
Mar 13 2015
parent "karl" <ultrano hotmail.com> writes:
Read-up on what sRGB and AdobeRGB is...
Mar 13 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 March 2015 at 09:54, karl via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 I'm unsure of the "gamma" space, Adobe should be enough to cover things (the
 curve is practically identical). Still, they are different at 0xA7 and 0xBE,
 so maybe useful for some files. GPUs and every non-specialized monitor only
 do sRGB<->linear.
 So, all's good with that pull request, just "gamma" might be useless and
 confusing.


'gamma' is used in many performance-oriented applications, because
it's MUCH faster to calculate/convert than sRGB (which is completely
mental).

Note, I still have a LOT of work to do on that module, I'm not really
happy with it. But I wanted to try that approach out.
I think I'm leaning more towards explicit types for different
high-level colour spaces after experimenting with that design. I'll
probably leave selection of colourspace detail to template arg though
(sRGB/linear/etc).
Apr 12 2015
prev sibling next sibling parent "Aram" <a mailinator.com> writes:
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a 
 good foundation, but had very restrictive license. Things have 
 changed since then, and Qt now is available under LGPL, which, 
 to my undestanding, makes it suitable for the purpose of 
 standard GUI library (please correct me if I am wrong on this). 
 The license, of course, may change in the future, preventing us 
 from using their updates for our drawing engine. But if we are 
 able to start using the engine now, in the future we can 
 maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for drawing 
 engine and event loop, which are system-dependent. Those two 
 parts will be extracted from Qt into a separate library which 
 will be linked to by the rest of framework either statically or 
 dynamically. There will be bindings for sending drawing 
 instructions to drawing engine, as well as for retrieving 
 system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. 
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


 If there is no standard GUI for D yet, and if LGPL license fits 
 our purpose, then I am looking for 2-3 Qt experts to join me 
 and build the framework.

 Thanks,
 Aram


Forgot to mention that the backend should be able to work with 
native fonts.
Mar 05 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.


The only reasonable approaches these days are either:

1. A thin native wrapper that is specific for each platform with 
near full mapping to native GUI features.

2. A HTML5 render engine with a convenient marshalling system.

3. A very efficient OpenGL based composite engine that do 60hz 
redraws and that can be integrated in a fullscreen OpenGL 
app/game. This is really the best approach now that mainstream 
GPUs can do 60hz refresh without hickups. But it is not easy to 
get right.

Anything less that that will only end up with something that is 
done better by existing cross platform frameworks, and they 
aren't great due to deliberate incompatibilities between native 
GUI systems. Qt, Gtk etc does not provide great UI experiences 
imho. They are incapable of keeping up with developments on the 
OS platforms and are going to die a slow death...
Mar 06 2015
parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Friday, 6 March 2015 at 09:09:43 UTC, Ola Fosheim Grøstad 
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.


 The only reasonable approaches these days are either:
 ...
 3. A very efficient OpenGL based composite engine that do 60hz 
 redraws and that can be integrated in a fullscreen OpenGL 
 app/game. This is really the best approach now that mainstream 
 GPUs can do 60hz refresh without hickups. But it is not easy to 
 get right.
 ...


DlangUI does it if built with version=USE_OPENGL

Can draw UI on top of OpenGL scene.
Mar 06 2015
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:

 Hi all

 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.

 In that duscussion many participants agreed that Qt would be a 
 good foundation, but had very restrictive license. Things have 
 changed since then, and Qt now is available under LGPL, which, 
 to my undestanding, makes it suitable for the purpose of 
 standard GUI library (please correct me if I am wrong on this). 
 The license, of course, may change in the future, preventing us 
 from using their updates for our drawing engine. But if we are 
 able to start using the engine now, in the future we can 
 maintain the updates ourselves.

 Now, how I envision the library's design:

 The library will be mostly implemented in D, except for drawing 
 engine and event loop, which are system-dependent. Those two 
 parts will be extracted from Qt into a separate library which 
 will be linked to by the rest of framework either statically or 
 dynamically. There will be bindings for sending drawing 
 instructions to drawing engine, as well as for retrieving 
 system and GUI events from event loop.

 The system-independent part will mimic architecture of Qt. 
 However, for maximum flexibility and customizability, GUI will 
 utilize QML+CSS approach, and Qt's layout manager classes will 
 be dropped completely. Also there is no need to port classes 
 that are available in D, such as collections and strings.


 If there is no standard GUI for D yet, and if LGPL license fits 
 our purpose, then I am looking for 2-3 Qt experts to join me 
 and build the framework.

 Thanks,
 Aram


I would rather have a GUI framework inspired by JavaFX, plus some 
features that could be added on top of it, that are related to 
the fact that D programmers can utilize hardware directly. JavaFX 
is in my humble opinion one of the best designed GUI APIs in 
existence today. Similar D API would be smaller because we would 
get rid of typical Java bloat.
Mar 09 2015
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2015-03-09 at 08:56 +0000, Dejan Lekic via Digitalmars-d wrote:
[…]

 
 I would rather have a GUI framework inspired by JavaFX, plus some 
 features that could be added on top of it, that are related to 
 the fact that D programmers can utilize hardware directly. JavaFX 
 is in my humble opinion one of the best designed GUI APIs in 
 existence today. Similar D API would be smaller because we would 
 get rid of typical Java bloat.


And using GroovyFX to code it gets rid of much of the Java bloat. Sadly
the JavaFX team have created a nice piece of infrastructure but forget
to mention that coding it using Groovy is way easier that using Java.

Of course using a UI development framework such as Griffon makes things
even easier.

http://new.griffon-framework.org/


-- 
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
Mar 09 2015