Ideal D GUI Toolkit

[Adam Wilson]

On Mon, 20 May 2013 20:32:30 -0700, Tyler Jameson Little  
<beatgammit at 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/