Ideal D GUI Toolkit

[Adam Wilson]

On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little  
<beatgammit at gmail.com> wrote:

>>> I'd love to get this up and running but I think we've got a blocker
>>> right now in D and that is the lack of package import,
>>> the GUI system is
>>> going to be a monster no matter how it's sliced and I'd lack to avoid
>>> the std.datetime effect. Sorry Jonathan Davis!
>>
>> Why do you need package import?  Can't you achieve the equivalent by  
>> having one module that imports all the others publicly leaving the  
>> application programmer only one module to import?
>
> I also agree. But a package import is in the works apparently, so by the  
> time something is ready to show, the feature will be there. Just shim  
> for now (with an all.d or whatever) and get stuff done. I think we're  
> looking at a 1yr or so investment before trying to include in Phobos  
> becomes a consideration.
>
>>> Once we get package import into D we can start building out the basics.
>>> Do you have any experience with concurrent hashmaps by chance?
>>
>> No. Why do you want concurrency? Aren't associative arrays hashmaps?   
>> My only experience with hashing techniques (other than as an end user  
>> of classes/functions/features using them) was implementing git binary  
>> patches in Python for use in one of my GUIs.
>
> I agree. UIs are asynchronous by nature, not concurrent. If we agree on  
> this premise, basic associative arrays can be used, and all access to  
> them can be guarded by a simple mutex.
>

See my DConf talk in a few days (I was #3 on Day 2). It has a pattern for  
concurrent data mutation at the end that might be more useful than a  
global lock, which has some pretty disturbing implications for  
high-performance rendering code.

> I'm completely willing to head up the initial development. I probably  
> won't get anything done, and any initial work will be Linux-specific (I  
> honestly don't care about Mac OS X or Windows). If anything does get  
> done, I'll definitely come back here to get help on the design. I'm  
> willing to do some leg-work, but I'm not experienced in any way, shape  
> or form with GUI development (most of my work is server-type stuff in Go  
> or front-end stuff in JS/HTML5/CSS3).
>

As far as rendering goes I was think about designing something pluggable,  
so it would have to follow a defined interface. It might be good to at  
least sketch out what that interface needs. It should be as simple as  
possible, basically just the primitives and anything needed to accurately  
render the visual tree.

> If we're generally in agreement that a UI toolkit is a good direction,  
> I'd love to waste the next few months of my life doing something that  
> likely won't go anywhere. I personally think it's much more exciting to  
> make something in native D instead of trying to work around the lack of  
> concern other C++ toolkits like Qt have for cross-language portability.

I can't tell if this is snark or not so I'll assume it isn't. :-) I don't  
know how likely cross-language portability is to be achieved by any UI  
toolkit, way to many things that need more advanced language features. If  
we use D we'd probably end-up using a non-portable set of language  
features anyways...

It'd be nice, but given how constraining C++ is compared to D it might not  
be practical in the long run. Although the rendering interface might be  
able to plug with D. That should be simple enough...

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