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.

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

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!
> 
> 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.
> 
> 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" 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 graphic system author has to rewrite the whole thing (as 99% of code is in "backend", and have to be rewritten). so it's easier to drop all that mess and just write direct X11 calls. that's exactly what you are proposing: a single "backend" handle and alot of "frontend" functions that manipulates that handle.

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.

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.

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

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

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. ;-)
> 
> 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 like it's core simplicity (oh, no, full xorg is a beast, especially with crap like xrender and dropping XIE!). and i really like network transparency (yep, it works! ;-).

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!

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?