Ideal D GUI Toolkit

Tyler Jameson Little beatgammit at gmail.com
Mon May 20 20:32:30 PDT 2013


> So the basic premise of the argument is that if we can't make 
> everyone happy we shouldn't do anything at all?

That's the initial feeling I get, but I think it comes more from 
the idea that a large piece of software they didn't write might 
be dumped on them. It's a legitimate concern, so I think a GUI 
library should not be included in Phobos if a group has not 
agreed to maintain it.

> Also, mobile, particularly WinRT, but also Android, do not 
> enforce a look, in fact Android enshrines the idea of many 
> different looks for widgets, my S3 is NOT the vanilla Android 
> look. Only iOS enforces a "look" but it's still overridable. 
> And WinRT doesn't even have the concept of OS enforced widgets 
> looks, all it has a default style.

Trying to cover all bases seems like a headache that doesn't make 
sense in a standard library. For me, a standard library would 
provide a simple way to get basic tasks done; anything more 
complicated should be built on top if possible, but the core 
shouldn't be too bloated.

I'm thinking something closer to Clutter, not WPF. WPF is fine, 
but as you mentioned earlier, it has something like 40,000 
classes. I'm sure much of it is just OO baggage (stupid little 
20-line classes), but that still translates to a lot of code. 
Browsing Ohloh.net, here's an idea of the scope of other FOSS GUI 
toolkits:

* Qt 5 - ~7.7 million SLOC
* wkWidgets - ~1.3 million SLOC
* Gtk+ - ~769k SLOC
* EFL - ~535k SLOC
* Clutter - ~133k SLOC

As for my opinionated ideals (doesn't affect the overall design 
much):

* no XML (yaml maybe, but XML just isn't user-friendly)
* very limited number of default components (external libraries 
can provide more)
* liberally licensed (Phobos requires Boost, so that's a minimum; 
I prefer BSD)

I also don't like the idea of external processes interfering with 
the UI. I can only see security holes that cannot be plugged 
because of the design decision. This can, of course, be provided 
by a developer, but it should not be provided by default in the 
library code.


More information about the Digitalmars-d mailing list