March 05, 2015
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.

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

March 05, 2015
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.

March 05, 2015
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.
March 05, 2015
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.

March 05, 2015
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 (as we doesn't store it's coordinates), no way to... no way to define anything. that's will be great GUI!

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. it's cool.


> Winforms is simple and absolutely agnostic about controls.

winforms sux. dixi.

March 05, 2015
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.
> 
> 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.

to be honest, i prefer to use X11 even for windows. if i need to port some of my GUI code to windows... well, working X11 server is prerequisite. cygwin's, for example. ;-)

March 05, 2015
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.
March 05, 2015
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).
March 05, 2015
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.
March 05, 2015
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.