I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion.

First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion.

Personally, I want these features:

* simple and extensible
  * minimal components (something like HTMLs feature-set)
  * custom components (embed OpenGL/direct frame buffer)
* "native" window decorations by default, but can provide custom decorations
* markup (like QML) or programmable (like SWT)

Nice-to-haves:

* hardware accelerated (2D OpenGL)
* GUI designer (much easier with QML-esque markup)
* part of Phobos

I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos.

Thoughts?

On Monday, May 20, 2013 07:25:49 Tyler Jameson Little wrote:
>  I'd also like to know
> the likelihood of getting a GUI toolkit into Phobos.

It's come up before, and I don't think that any sort of decision has ever been made on that, though personally, that strikes me as the sort of thing that doesn't really belong in the standard library. Certainly, if it did end up in there, it would probably have to be very minamalistic.

Also, I thought that general consensus had been that while it would be awesome to have a GUI toolkit written in D at some point, that's the sort of thing that takes a ton of time and effort, and we have enough other stuff that needs doing that the time and effort of the community was better spent on other things and that wrapping a C++ GUI toolkit was a better move for the forseeable future (with a full D GUI toolkit being something that might happen once D is much larger). But anyone who wants to work on a GUI toolkit in D is welcome to do it. IIRC, there was at least one small one done in D1 using OpenGL. And having at least a minimal one so that very basic GUIs could be written fully in D would certainly be very cool.

Personally, I have too much other stuff to do and not very much expertise in this area, so it's the sort of thing that I'm very unlikely to be involved in and am likely to leave most of the decisions up to others who are much more versed in this sort of thing.

- Jonathan M Davis

On 2013-05-20 07:25, Tyler Jameson Little wrote:
> I've been looking into trying to fix QtD, but it seems writing a binding
> to a C++ library is a bit complicated. I've read on the forums that a
> native D GUI toolkit is the most desirable long-term, so I'd like to
> start that discussion.
>
> First off, I've heard of the DWT project, which looks promising, but it
> seems like a direct port of Java's SWT instead of a reimagining using
> idiomatic D. I understand the allure here (works, little translation for
> new developers), but since it's not yet in Phobos, I can only assume
> it's still up for discussion.
>
> Personally, I want these features:
>
> * simple and extensible
>    * minimal components (something like HTMLs feature-set)
>    * custom components (embed OpenGL/direct frame buffer)
> * "native" window decorations by default, but can provide custom
> decorations
> * markup (like QML) or programmable (like SWT)
>
> Nice-to-haves:
>
> * hardware accelerated (2D OpenGL)
> * GUI designer (much easier with QML-esque markup)
> * part of Phobos
>
> I'm willing to lend a hand, but I'd like to know in what direction the
> community would like to go. I'd also like to know the likelihood of
> getting a GUI toolkit into Phobos.
>
> Thoughts?

Creating a new GUI toolkit is a huge amount of work. It's more than you can imagine. A GUI toolkit for creating a window with a button isn't that much work. But it's all the rest of the stuff, that a toolkit can do and people will expect from it. Like stuff you didn't think of or even didn't know they existed.

A GUI toolkit in Phobos will probably not happen.

-- 
/Jacob Carlborg

> It's come up before, and I don't think that any sort of decision has ever been
> made on that, though personally, that strikes me as the sort of thing that
> doesn't really belong in the standard library. Certainly, if it did end up in
> there, it would probably have to be very minamalistic.

That's exactly what I want, something to build off of. I'm thinking modeling it on Clutter or something like this: http://swtch.com/~rsc/thread/cws.pdf. The link is to a simple, nested windowing system that serves as the basic architecture of the Plan9 GUI. It's super simple and flexible. Everything would be asynchronous, and only the most essential components would be provided.

> Also, I thought that general consensus had been that while it would be awesome
> to have a GUI toolkit written in D at some point, that's the sort of thing
> that takes a ton of time and effort, and we have enough other stuff that needs
> doing that the time and effort of the community was better spent on other
> things and that wrapping a C++ GUI toolkit was a better move for the
> forseeable future (with a full D GUI toolkit being something that might happen
> once D is much larger). But anyone who wants to work on a GUI toolkit in D is
> welcome to do it. IIRC, there was at least one small one done in D1 using
> OpenGL. And having at least a minimal one so that very basic GUIs could be
> written fully in D would certainly be very cool.

That's the feeling I got. If it's designed well, it might be one of the major things that draws people to D, and everyone would benefit from that.

I'm willing to work on one, but I don't want to duplicate effort if the community is already standardizing on something. I ran into that earlier when I tried to expand std.json, only to find out that a std.serialize was in the works, hence the question.

I can't say I'm an expert, but I've got a little extra time and I want to eventually build a game in D, and I need something to build off of.

"Tyler Jameson Little" <beatgammit@gmail.com> wrote in message news:vtaufckbpdkpuxyztyoi@forum.dlang.org...
> I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion.
>
> [snip]
>
> Thoughts?

I don't know much about Qt's source, but automatic conversion to D, like we are doing for the compiler, might be worth looking into.  If it is written in modern-ish C++ (not too many preprocessor hacks), which from a quick look it appears to be, this might be a much more reasonable task than writing a new gui lib from scratch.

On Tuesday, May 21, 2013 03:33:01 Daniel Murphy wrote:
> I don't know much about Qt's source, but automatic conversion to D, like we are doing for the compiler, might be worth looking into. If it is written in modern-ish C++ (not too many preprocessor hacks), which from a quick look it appears to be, this might be a much more reasonable task than writing a new gui lib from scratch.

IIRC, they use macros quite a bit for various stuff (like signals and slots), and they have their own version of make to set up some stuff for you. So, my first guess is that conversion would be a bit of a beast. But it's been a while since I did much with Qt.

- Jonathan M Davis

On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little <beatgammit@gmail.com> wrote:

> I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion.
>
> First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion.
>
> Personally, I want these features:
>
> * simple and extensible
>    * minimal components (something like HTMLs feature-set)
>    * custom components (embed OpenGL/direct frame buffer)
> * "native" window decorations by default, but can provide custom decorations
> * markup (like QML) or programmable (like SWT)
>
> Nice-to-haves:
>
> * hardware accelerated (2D OpenGL)
> * GUI designer (much easier with QML-esque markup)
> * part of Phobos
>
> I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos.
>
> Thoughts?

So I've been around D a while pushing for native D UI toolkit. And here are a few trends I've seen in the community.

* There is a deep-seated distrust of any toolkit that does not use the OS Native UI widgets. The people in this community prefer native toolkits to the point of jihad. Now I am a XAML guy myself, and I saw the light a long time ago, but around here, the majority are still command line gurus.
* There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there. GUI toolkits are too use-case specific to belong in a standard library. However, if we can make (and I think we can) a truly cross-platform UI toolkit, we can make a stronger case for using at a standard UI toolkit.
* Nobody believes that we can do it, you'll hear a lot of moaning about how much work it is. My reply to that is: And Linux is such a piece of cake right? It's only the most widely used kernel on the planet.

Here's the deal. Building a GUI toolkit, particularly a useful one, is a massive undertaking. WPF is the single largest library in all of .NET. IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will require something that D itself does not. A highly dedicated team of people with many diverse skills. The project is simply too big for a single person.

Part of the problem with UI toolkits is the number of skills you'll need for the team. Graphics programmers who can make GPU's sing, API designers who can make it easy access, UI designers capable of replicating the looks of each OS. Experts for each targeted OS. And I can think of more.

My point here is not to be discouraging, I want a UI toolkit with capabilities similar to WPF in D probably more than anybody else here. But I want to be realistic about the effort required. The dedication required is immense, you'll be writing code for months before you even get anything on the screen.

Here is another factor to consider. A UI toolkit must be designed. You won't have the luxury of Phobos of design-by-iteration simply because you'll be throwing out entire systems. For example a fairly complete render path is required before you can show anything on the screen. But what happens when your render-path is too OS specific? Oops, you pitch months of work and start over from scratch. But now you have to rebuild everything you've built on top of it. Do that a few times and you'll give up because you can never seem to get anywhere. The smart thing to do is sit down with a knowledgeable group of people and design the system, the design doesn't have to be perfect or complete, but it does need to provide a framework to work within and vision to guide the team.

Lastly, we'll need something that D doesn't have much of, but Linux does. Leadership. You can't pull together something this complex without someone or someones holding the bigger picture in their heads, otherwise you'll end up with a mish-mash of contradictory merged pulled requests.

In my experience in Open-Source, it's never a problem to find people who have vision and want to lead a project. The problem is finding people who agree with the vision enough to help without wanting to be in charge because they really know better. FOSS's major drawback is the ridiculous amounts of duplication. I don't see a WPF-style UI toolkit as duplication because as near as I can tell there is nothing like WPF in the OSS world, but, everybody has their own opinion about HOW it should be done and almost nobody is willing to swallow their ego, quit sweating the small stuff, and work towards a common goal, even if they don't agree 100%.

A UI toolkit in D would be a fantastic showcase for demonstrating just how powerful D is. But make no mistake, it will not be easy getting it done.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 07:25:49 +0200, Tyler Jameson Little wrote:

> I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion.
> 
> First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion.
> 
> Personally, I want these features:
> 
> * simple and extensible
>    * minimal components (something like HTMLs feature-set)
>    * custom components (embed OpenGL/direct frame buffer)
> * "native" window decorations by default, but can provide custom
> decorations * markup (like QML) or programmable (like SWT)
> 
> Nice-to-haves:
> 
> * hardware accelerated (2D OpenGL)
> * GUI designer (much easier with QML-esque markup)
> * part of Phobos
> 
> I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos.
> 
> Thoughts?


FLTK might be easier the Qt.  Also libcairo maybe used if you build one yourself.

On Mon, 20 May 2013 11:01:35 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:
> 
> Graphics programmers who can make GPU's sing,
[...]
> UI designers capable of replicating the looks [REPLYER'S EDIT: "and feel"] of each OS.
> 

Embrace native and those two concerns disappear.

And that latter of those two is *NEVER* going to be pulled off successfully with a non-native toolkit anyway.

On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 11:01:35 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>>
>> Graphics programmers who can make GPU's sing,
> [...]
>> UI designers capable of replicating the looks [REPLYER'S EDIT: "and
>> feel"] of each OS.
>>
>
> Embrace native and those two concerns disappear.
>
> And that latter of those two is *NEVER* going to be pulled off
> successfully with a non-native toolkit anyway.
>

Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and WPF (retained mode GPU rendering) are pixel identical. Only way to tell the difference is if it doesn't use the default (native) styling. Nick, I work exclusively in WPF/XAML all day every day at work, but the last app I wrote was WinForms, what's your experience?

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/