Ideal D GUI Toolkit

[Adam Wilson]

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

> 20-May-2013 23:41, Adam Wilson пишет:
>> On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky
>> <dmitry.olsh at 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/