On Mon, 20 May 2013 20:26:29 -0700, Diggory <diggsey@googlemail.com> wrote:

> On Tuesday, 21 May 2013 at 02:47:59 UTC, Adam Wilson wrote:
>> could care less
>
> http://www.youtube.com/watch?v=om7O0MFkmpw
>
> Sorry...

I type quickly but not always accurately, I actually caught that right after hitting send.

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

On Mon, 20 May 2013 20:26:33 -0700, Peter Williams <pwil3058@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@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/

On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little <beatgammit@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/

On 5/20/13 9:49 PM, Peter Williams wrote:
>
> Yes, if D aspires to be a systems programming language it can't keep
> relying on wrappers around C/C++ libraries (especially C++).  In the
> long term, it should be D all the way down to the OS API.

You wrote this as if not using c and c++ libraries is a predicate for being a systems language.  It's not.

What's with the D community's (yes, I'm over generalizing some) not-invented-here syndrome?  Avoiding the incredible body of existing code out there that's accumulated over the decades is foolhardy and narrow sighted.  Are all c and c++ libraries great bodies of code, absolutely not.  Is some of the code that predates D worth reusing, yup.

Sigh,
Brad

> 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 can't help but feel that making them concurrent is going to provide very marginal benefits. Rendering code is already essentially concurrent since you don't usually block until the GPU is done rendering, you just tell it what to do and let it get on with it.

Also, there's no point doing multiple renders per UI update because you'll just be drawing the same thing, and no point doing multiple UI updates per render because in the end only the most recent update will be shown. Anything other than sequentially executing "render -> update -> render -> update" is redundant.

To me it makes more sense to do all the updating and rendering in a background thread with a thin layer over the top to hide the details of synchronising with this background thread from the programmer.

On Mon, 20 May 2013 23:00:10 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little <beatgammit@gmail.com> wrote:
> 
> > 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...
> 

I was thinking that starting out by building off of bindings to a C/C++ library could be a good idea for two reasons:

- Hedging bets. If the D-ification runs into any problems (either the
  project as a whole, or just a specific problem that a user needs to
  temporarily work around), there's always the raw binding to fall back
  on. Besides, any brand-new API/lib is naturally going to be riskier
  than bindings to a proven one.

- Bootstrapping. I find that building off an existing thing, even if
  you just end up replacing it with a homemade solution later
  (usually piecemeal), helps get the project jump-started, which gets
  you to more important things (such as a usable/stable state) earlier,
  which also helps maintain morale and momentum.

On Mon, 20 May 2013 23:21:28 -0700
Brad Roberts <braddr@puremagic.com> wrote:

> On 5/20/13 9:49 PM, Peter Williams wrote:
> >
> > Yes, if D aspires to be a systems programming language it can't keep relying on wrappers around C/C++ libraries (especially C++).  In the long term, it should be D all the way down to the OS API.
> 
> You wrote this as if not using c and c++ libraries is a predicate for being a systems language.  It's not.
> 
> What's with the D community's (yes, I'm over generalizing some) not-invented-here syndrome?

Conditioned aversion to C++? (half-serious)

> Avoiding the incredible body of existing
> code out there that's accumulated over the decades is foolhardy and
> narrow sighted.  Are all c and c++ libraries great bodies of code,
> absolutely not.  Is some of the code that predates D worth reusing,
> yup.
> 
> Sigh,
> Brad
> 

On 21/05/13 16:21, Brad Roberts wrote:
> On 5/20/13 9:49 PM, Peter Williams wrote:
>>
>> Yes, if D aspires to be a systems programming language it can't keep
>> relying on wrappers around C/C++ libraries (especially C++).  In the
>> long term, it should be D all the way down to the OS API.
>
> You wrote this as if not using c and c++ libraries is a predicate for
> being a systems language.  It's not.

It is for me. I also won't count D as a systems language until DMD is implemented in D.

>
> What's with the D community's (yes, I'm over generalizing some)
> not-invented-here syndrome?  Avoiding the incredible body of existing
> code out there that's accumulated over the decades is foolhardy and
> narrow sighted.

I did say "in the long term".

> Are all c and c++ libraries great bodies of code,
> absolutely not.

I am not a fan of C++ (and don't really trust C++ libraries).  I went to C++ from Modula-2 due to job constraints but eventually ditched it and moved on to C - yes, I went from C++ to C.  The main reasons were that I felt C++ caused more problems than it cured.  Plain C is a perfectly good language for OOP as GTK+ demonstrates and there's no need for all the complexity that comes with C++.

>  Is some of the code that predates D worth reusing, yup.

Yes, but "in the long term" it should be replaced by D code so that you get all the many advantages (better testing, contracts, simplicity, etc.) that brings.  Redo the ones that suck first but do them all eventually.

Peter

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

A little bit of snark, but there's some truth there. I realize that my work will likely come to naught, but I think it's an interesting project none-the-less. I'm tired of the industry's focus on C++, and it seems that most people have come to accept it. C++ devs I know would gladly move to D, if it had proper tools, such as a GUI library.

Personally I hate C++; I find it to be a terribly confusing language with no real benefit, except the availability of libraries, which isn't even a language feature. I do, however, think that whatever D uses should be relatively portable. I'm not sure how easy it is to import D code into C++, but it seems to be possible.

Maybe I'll just have a go and check back once you're done with you're bickering ;)

On 2013-05-20 19:42, Jonathan M Davis wrote:

> IIRC, they use macros quite a bit for various stuff (like signals and slots),
> and they have their own version of make to set up some stuff for you. So, my
> first guess is that conversion would be a bit of a beast. But it's been a while
> since I did much with Qt.

They have (or used to have) a special compiler to collect metadata used for reflection and similar.

-- 
/Jacob Carlborg