Ideal D GUI Toolkit

[Adam Wilson]

On Mon, 20 May 2013 20:26:33 -0700, Peter Williams  
<pwil3058 at bigpond.net.au> wrote:

> On 21/05/13 12:53, Adam Wilson wrote:
>> On Mon, 20 May 2013 16:50:47 -0700, Peter Williams
>> <pwil3058 at bigpond.net.au> wrote:
>>
>>> On 21/05/13 08:49, Adam Wilson wrote:
>>>>
>>>> I'd be willing to lead the project, I'm just not sure I am the right
>>>> person to do so. I have a vision, and the skeleton of a design, but no
>>>> code. I am willing, but my ability is a question mark...
>>>>
>>>
>>> I'd volunteer to be a foot soldier on this project as I'd like D to
>>> have a useful GUI capability.  At the moment, my experience of GUI
>>> programming is at the user of the API end of the spectrum (mostly
>>> using PyGTK to write GUI wrappers for command line programs to make my
>>> life easier) but I think I'm a quick learner.  Also as a GUI API user
>>> I have some idea of the sorts of thing that make a good API.
>>>
>>> If D had a usable GUI API I would port at least one of my current
>>> PyGTK programs to D as it would benefit from better number crunching
>>> capability than Python possesses.
>>>
>>> So, if this gets up, give me a call.
>>> Peter
>>>
>>
>> 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?
>

You can but it's a hack that doesn't always work well. That said for  
initial development it would work fine.

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

Well, it comes down to how you want to render. My preferred solution  
woulbd be a rendering thread running all the time doing nothing but the  
GPU leg-work, then have a UI thread thread were the work of maintaining  
the UI would get done. That thread would periodically update the render  
thread. I discussed a concurrent data mutation pattern in my DConf talk  
that could be used to make this update process simpler and less error  
prone (lock avoidance). It'll probably be online next week or the one  
after.

>> Or any
>> other types of containers?
>>
>
> I implemented a "left leaning red black" tree in Go (as a basis for  
> implementing various "set" containers) a while back before I abandoned  
> Go due to their silly "inject ';' at the end of lines" hack in the  
> lexical analyser.  Also, the basis of my PhD thesis was the equivalent  
> of an optimal redundant discrimination tree which is a kind of container  
> albeit fairly specialised.
>
> Peter

Interesting... :-)

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