20-May-2013 22:01, Adam Wilson пишет:
> 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.

It's just one crazy Nick ;)

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

Markup for GUI layout seems like a decent idea.

> * There is absolutely no chance of inclusion in Phobos, and to-be-honest
> I don't think it really belongs there.

Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!)

[snip]

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

If anything D community is full of people doing things close to impossible (esp given the limited spare time and other constraints).

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

I sure hope savings in amount of idiomatic D code vs C# idiomatic code OOP code could help here.
>
> 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.

Well, then you'll also become an expert in a couple of cool fields ;)
Seriously a few helping hands are sorely needed.

[snip other good points]

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


-- 
Dmitry Olshansky

On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 20-May-2013 22:01, Adam Wilson пишет:
>> 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.
>
> It's just one crazy Nick ;)
>

Well, there are a couple vocal others.

>> 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.
>
> Markup for GUI layout seems like a decent idea.
>

HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is markup. Android is markup. Realistically, the age of OS native toolkits has passed, markup is the future. *shrug* For me it's a practical thing, markup is extensible, OS widgets are not.

>> * There is absolutely no chance of inclusion in Phobos, and to-be-honest
>> I don't think it really belongs there.
>
> Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!)
>
> [snip]
>

I would LOVE to see it included in Phobos, but making it multi-platform places an pretty hard requirement that it not be OS native widgets, some OS's have widgets that others don't, some OS's have incompatible UI declaration models, for example: WinForms is Win23 API calls where iOS is markup. It is workable, but it is even MORE work than building a GPU based UI toolkit from scratch. How big is Qt compared to WPF?

>> * 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.
>
> If anything D community is full of people doing things close to impossible (esp given the limited spare time and other constraints).
>

Agreed. But as soon as you bring up UI toolkits then it's too much, it's impossible, it makes no sense, etc, etc, etc. That's kind of my point, D takes the "impossible" and makes is merely difficult.

>>
>> 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.
>
> I sure hope savings in amount of idiomatic D code vs C# idiomatic code OOP code could help here.

You have no idea...

>>
>> 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.
>
> Well, then you'll also become an expert in a couple of cool fields ;)
> Seriously a few helping hands are sorely needed.
>

Absolutely, but my point is that some of those are entire fields of study and bodies of knowledge that can take years or decades a too acquire. It's a bit unrealistic for first time GPU coder to write an efficient shader. UI design is a whole field unto itself. Etc. My point here is that no one person has a realistic shot of being able to acquire and maintain the required knowledge single-handedly.

> [snip other good points]
>
>> 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 12:28:09 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

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

WPF/XAML is first-party, therefore it's native by definition regardless of whether or not it internally hands off to the older UI code. Saying WPF isn't native is like saying that Quartz isn't native just because it doesn't use...uhh, whatever the UI was called in Mac OS 9.

Besides, having access to all of MS's internal code, documents, probably even some of the original developers still around, etc., is naturally going to change the feasibility in a way that no third party toolkit (which is exactly what we're talking about here) is realistically going to be able to match.

In other words, despite your antagonism, I was implicitly **agreeing** with your assertion that it's one a hell of an undertaking, *especially* if you don't make use of native APIs under-the-hood.

On Monday, 20 May 2013 at 19:41:09 UTC, Adam Wilson wrote:
> Well, there are a couple vocal others.

My preference for native stuff is just simply that the alternative seems to be reinventing a gigantic wheel.

Though, at the same time, for a while I was playing with the idea of using my simple htmlwidget.d as a gui thing. It can only handle simple html.... but that does include events, and we can get quite a bit done with crappy html. In theory, we could write up all kinds of tags and make something out of it.

But I don't do enough gui stuff anymore to worry much about it personally.

On Monday, 20 May 2013 at 05:25:50 UTC, Tyler Jameson Little wrote:
> Thoughts?

I don't think it will make it in Phobos. At least not for a long time. It will first need to be proven and show a strong use in the community/world.

As said, it is a massive undertaking so people are skeptical and I like the point made that it will require collaboration from many knowledge areas.

Linux was mentioned. Just remember Linus is just building an OS for fun, trying to see if he can mimic Unix on his system. He doesn't have any interest in supporting hardware non-SCSI (or something like that) since he doesn't have a machine with that hardware. The fact that others are providing support for those things and he is merging them in is irrelevant.

I like DWT, but it is a lot to learn. I've been using DFL and wish to switch to DWT but re-writing my simple GUI isn't a priority. DWT could use a D face, but I'm ok with examples compiling with little change.

On Mon, 20 May 2013 23:28:16 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 20-May-2013 22:01, Adam Wilson пишет:
> >
> > * 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.
> 
> It's just one crazy Nick ;)
> 

Heh :) It's really not just me, though. But, gee, it is nice to know I'm in people's thoughts...I think... ;)

> > 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.
> 
> Markup for GUI layout seems like a decent idea.
> 

Indeed. XML wouldn't have been my choice though, but UI layout is an appropriate area for some DSL-ness.

> > * There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there.
> 
> Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!)
> 
> [snip]

There's interest, sure, but it'd have to be really, *really* freaking
good. Enough to obviate most needs/desires for the other popular
GUI toolkits. It'd have to do for us what WPF did for MS, *and* be
cross-platform. Not impossible, strictly speaking, but a tall order
even for us.

Not saying it isn't worth attempting for those skilled and motivated enough, but I wouldn't have my hopes up. And I'm not sure how much we'd really gain by having it in phobos anyway: By the time any toolkit like that was built and ready, I'm sure DUB will have gotten big enough that being an external library won't be an issue.

On Mon, 20 May 2013 12:41:08 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> >
> > Markup for GUI layout seems like a decent idea.
> >
> 
> HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is markup. Android is markup. Realistically, the age of OS native toolkits has passed, markup is the future. *shrug* For me it's a practical thing,

And what takes that markup and actually executes it? Magical GUI fairies? ;)

Markup is, by necessity, nothing more than a front-end for a code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI toolkits will always be there whether it's the UI designers that use it directly or the markup developers that use it directly.

>markup is extensible, OS widgets are not.
> 

I don't know where you got that idea.

20-May-2013 23:41, Adam Wilson пишет:
> On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky
> <dmitry.olsh@gmail.com> wrote:
[snip]

>
>>> * There is absolutely no chance of inclusion in Phobos, and to-be-honest
>>> I don't think it really belongs there.
>>
>> Where you take that from? I thought it was quite the opposite if
>> written in D. Even C++ guys seem interested in GUIs in std library(!)
>>
>> [snip]
>>
>
> I would LOVE to see it included in Phobos, but making it multi-platform
> places an pretty hard requirement that it not be OS native widgets, some
> OS's have widgets that others don't, some OS's have incompatible UI
> declaration models, for example: WinForms is Win23 API calls where iOS
> is markup. It is workable, but it is even MORE work than building a GPU
> based UI toolkit from scratch. How big is Qt compared to WPF?

Keep in mind that Qt as other frameworks basically bend the whole world into a certain ideology. They build everything anew from atoms (or rather quarks) up. Strings(!), smart pointers, events, semaphores, threads,  containers, allocators, signals/slots, you name it - they build it ALL.

Not to blame them - C++ std simply doesn't have it/cut it. D on the other hand can leverage the incredibly flexible (but incomplete currently) "framework" of Phobos.

Note that all of GUI frameworks are pre C++11 (hint-hint).

>>>
>>> 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.
>>
>> I sure hope savings in amount of idiomatic D code vs C# idiomatic code
>> OOP code could help here.
>
> You have no idea...

Of course, I haven't seen the video yet :)

[snip]
>>
>> Well, then you'll also become an expert in a couple of cool fields ;)
>> Seriously a few helping hands are sorely needed.
>>
>
> Absolutely, but my point is that some of those are entire fields of
> study and bodies of knowledge that can take years or decades a too
> acquire.

I believe this is a fallacy as given the current pace of progress people can then no longer hope to become experts anymore ;)
(Or at least in anything even remotely actual). A year or 2 is more then enough to get to the state of the art, and amount of experience is not proportional to inventing something new (and advancing the field).

Another thing to understand is that for example it took years to develop classical analysis in math but nowadays it's just a couple of semesters. Stealing a good vision from other expert(s) is a good interim short-cut.

Also believe it or not there is a quite large intersections between all of fields you just listed (at least pair-wise).

> It's a bit unrealistic for first time GPU coder to write an
> efficient shader.

And these change often enough that 5-years old experience has little advantage - you still have to re-read all the specs again.

> UI design is a whole field unto itself. Etc. My point
> here is that no one person has a realistic shot of being able to acquire
> and maintain the required knowledge single-handedly.

The only path is to develop even in teams is having a good taste (=vision) and lead others to follow it. If you don't understand UI design at all chances to succeed with you at head are low, ditto GPUs ditto everything else.

>> [snip other good points]




-- 
Dmitry Olshansky

On Monday, 20 May 2013 at 05:25:50 UTC, 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?

What about D Forms Library (DFL)?
I didn't try it yet, but I've heard it's not bad.
https://github.com/Rayerd/dfl

The following will take much less time and can achieve good, native results quickly:

Design a user-code facing clean api using idiomatic D (front end code):
windows, widgets, callbacks via delegates, etc.
Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc.

This is what python does with matplotlib:
http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython,
tkinter, qt, macosx, or fltk, and also non interactive backends)
The user code stays clean, the results are native (depending on backend),
and the wheel is not reimplemented.

On Mon, May 20, 2013 at 1:20 PM, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 12:41:08 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>
> > On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> > >
> > > Markup for GUI layout seems like a decent idea.
> > >
> >
> > HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is markup. Android is markup. Realistically, the age of OS native toolkits has passed, markup is the future. *shrug* For me it's a practical thing,
>
> And what takes that markup and actually executes it? Magical GUI fairies? ;)
>
> Markup is, by necessity, nothing more than a front-end for a code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI toolkits will always be there whether it's the UI designers that use it directly or the markup developers that use it directly.
>
> >markup is extensible, OS widgets are not.
> >
>
> I don't know where you got that idea.
>
>