UI toolkits are a lot of work but they're not as unreasonably big as everyone seems to be suggesting... I've written a couple myself in a procedural language using Direct3D to draw everything. Had all the standard controls, various layout options, even a syntax highlighted code editor, clipboard interaction, keyboard focus, etc.

The main difficulties with doing the same thing in opengl and making it cross platform seem to be:
- Font rendering, especially with support for the combining unicode characters and RTL languages. It would probably be worth finding an existing library for this.
- Making it consistent with the host OS, it would be possible to have a number of skins for each OS but that would probably be breaking all sorts of copyright rules. Generating the skin on the fly using the native drawing commands shouldn't be too hard...

On the other hand you get the advantages of hardware acceleration and pretty much unlimited custom drawing capabilities and I'd expect to see a lot of interesting custom controls out there. I'd definitely favour this option!

A native OS UI would be less work - although you'd effectively need to write an implementation specifically for each OS, the OS would take care of most of it for you. The main problems here would be getting consistent behaviour across all OSes and also it would be a lot of work to add controls that don't already exist in the OS.


What would be neat is if there was a CTFE based compiler which took some form of markup describing part of the UI and converted it to D code. That way you could mixin bits of UI markup either from files or string literals, directly into your classes and it would be really easy to hook up events and things.

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

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

It's first party only insofar as it's Microsoft, but that's where it ends. WPF is DevDiv, Win32 (i.e. WinForms) is WinDiv, being completely separate divisions at a company like MS means they might as well be separate companies. And your Mac OS 9 analogy would be correct about the Win32/WinRT differences, but not WPF. WPF exists completely outside the scope of the OS.

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

And my point is that your assertion that it can never be done is patently untrue. If MS can do it, there is no technical barrier to FOSS doing it, other than our own mental conception of what we are capable of. The point about WPF is that the system is so flexible in it's rendering that you can precisely emulate any native OS toolkit, or go off in a completely new direction. I prefer that flexibility as a UI designer.

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

Now that I think we all agree on. It is hard, but I think it might actually be more difficult to create a unified (standard) library on top of the native toolkits for each OS supported in Phobos. The OS requirements for a rendered UI such as WPF are actually far fewer, basically just a direct connection to the GPU and a windowing mechanism, virtually every OS provides those, for example, OpenGL and X. Therefore building the amount of shim building required is MUCH smaller.

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

>
> 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.
>
>
The other advantage of this is we can have results early on (leveraging existing backends), but nothing prevents us to work in parallel on a backend that's purely written in D (written on top of opengl for example) if need be.

On Mon, 20 May 2013 13:20:22 -0700, 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? ;)
>

Depends on the system, in WPF the XAML is encoded into a binary form of XML and then the objects are deserialized at runtime. Note that given D's CTFE I would NOT choose this path for any D UI toolkit. D is perfect for a system where you use markup to declare your UI in a CTFE manner and then have the compiler do the dirty work of actually generating the code. Fast AND Simple, Go D!

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

I mean extensible in terms of look or style, sorry for the ambiguity. OS widgets require tons of custom coding to change the style, I've done it, and I hated every minute of it. But with WPF I don't even think twice, I just do it, because I can get the exact style in under an hour.

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

On Mon, 20 May 2013 13:58:04 -0700, Timothee Cour <thelastmammoth@gmail.com> wrote:

>>
>> 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.
>>
>>
> The other advantage of this is we can have results early on (leveraging
> existing backends), but nothing prevents us to work in parallel on a
> backend that's purely written in D (written on top of opengl for example)
> if need be.

Every design I've discussed with various people in the community relies on have a pluggable rendering backend. It's the only sensible way really, the best way to custom draw stuff on Windows is DirectX, whereas its OGL on Linux/Mac, or OpenGL ES on Android and iOS.

And by going straight for the lowest level of GPU interaction for each platform we avoid an extra layer of abstraction in the rendering pipeline, which is very performance sensitive.

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

On Mon, 20 May 2013 13:40:06 -0700, Diggory <diggsey@googlemail.com> wrote:

> UI toolkits are a lot of work but they're not as unreasonably big as everyone seems to be suggesting... I've written a couple myself in a procedural language using Direct3D to draw everything. Had all the standard controls, various layout options, even a syntax highlighted code editor, clipboard interaction, keyboard focus, etc.
>
> The main difficulties with doing the same thing in opengl and making it cross platform seem to be:
> - Font rendering, especially with support for the combining unicode characters and RTL languages. It would probably be worth finding an existing library for this.
> - Making it consistent with the host OS, it would be possible to have a number of skins for each OS but that would probably be breaking all sorts of copyright rules. Generating the skin on the fly using the native drawing commands shouldn't be too hard...
>
> On the other hand you get the advantages of hardware acceleration and pretty much unlimited custom drawing capabilities and I'd expect to see a lot of interesting custom controls out there. I'd definitely favour this option!
>
> A native OS UI would be less work - although you'd effectively need to write an implementation specifically for each OS, the OS would take care of most of it for you. The main problems here would be getting consistent behaviour across all OSes and also it would be a lot of work to add controls that don't already exist in the OS.
>
>
> What would be neat is if there was a CTFE based compiler which took some form of markup describing part of the UI and converted it to D code. That way you could mixin bits of UI markup either from files or string literals, directly into your classes and it would be really easy to hook up events and things.

As far as I am concerned this is pretty much the only way to do it. D's CTFE gives us so much power in the markup->code translation phase we'd be terminally stupid not to use it. :-D

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

On Mon, 20 May 2013 13:32:09 -0700, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

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

Agreed, however, I think with D/Phobos we are in a situation where we can go the WPF route and just build on top of the existing work instead of having to create a whole new "standard" library to accompany it.

>>>>
>>>> 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, the video isn't NEARLY that broad in scope, but I do find on average that the D code is about 10% smaller than equivalent C#. Although for certain use cases like UI declaration with CTFE it could be a LOT smaller.

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

There may be some truth to this, however, GPU's in particular remain an area where specialized knowledge is required. Ask Manu. ;-) That said, even if most of who we needed are generalists, we'd still need a small army of them. Now this is open-source, and we can actually find that small army. But organizing them is far more difficult than at a corporation, at least there you have some unifying vision from the top. Out here is FOSS land it's a free-for-all, and in projects of this scope that tends create many competing visions, and implementations. Subsequently teams fragment quickly and duplication settles in.

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

Sadly this is true, but you still have your domain experience, yes the details changed, but the general processes and procedures you are used to don't generally change that fast.

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

Some days I wish I had the charisma and vision to develop that team, because I badly want a D UI toolkit that can do with WPF can. I may or may not have the right vision, but I am no charismatic. ;-)


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

On Mon, 20 May 2013 13:36:42 -0700
Timothee Cour <thelastmammoth@gmail.com> wrote:

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

Yea, that would definitely be my approach, too.

On Mon, 20 May 2013 13:58:56 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 13:20:22 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> > On Mon, 20 May 2013 12:41:08 -0700
> > "Adam Wilson" <flyboynw@gmail.com> wrote:

> >> markup is extensible, OS widgets are not.
> >>
> >
> > I don't know where you got that idea.
> >
> 
> I mean extensible in terms of look or style, sorry for the ambiguity.

Ahh, ok, I wasn't actually sure exactly what sort of "extensible" you meant.

> OS widgets require tons of custom coding to change the style, I've done it, and I hated every minute of it. But with WPF I don't even think twice, I just do it, because I can get the exact style in under an hour.
> 

Honestly, I'd consider that a major downside: Anything that helps/encourages developers to disregard a user's system settings (style or otherwise) is a very bad thing, IMO.

Of course, if the toolkit automatically comes with a
guaranteed user-selectable setting, outside of the app's control, to
optionally disable any custom styling on a per-app or global basis, then
that's the best solution of all: It attracts the "To hell with the
user's system settings because *I* deserve to be in control of my user's
computer" crowd and then uses that to hand control *back* to the user,
where it belongs. I've often thought about developing a system like
that.

On Tue, 21 May 2013 00:32:09 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

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

With only a brief, cursory understanding of the current state-of-the-art, any attempts to "advance the field" automatically carry a high risk of *regression* under the false guise of advancement.

And I strongly believe that's already been happening *a lot* over the past decade. Wheels are being reinvented, only this time most of them are squares.


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

Well, there *is* that, too.