On Mon, 20 May 2013 20:32:30 -0700, Tyler Jameson Little
<beatgam...@gmail.com> wrote:
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.
I actually find WPF too be far to heavy to be realistic for our purposes
too. I know why they choose XML for XAML (they had existing XML
parser/serialization libraries to leverage) but it ends up being
frighteningly verbose. I am think a DSL and CTFE/mixins would be a MUCH
more compact system and would be much more in line with D's principles. I
personally have no problem with Boost, the goal is to get people using it
in all scenarios, not restricting it to one licensing ideology or another.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
