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