WPFfor d

[Adam Wilson]

On Mon, 18 Feb 2013 01:33:51 -0800, Jacob Carlborg <doob at me.com> wrote:

> On 2013-02-18 09:59, rumbu wrote:
>
>> WPF is far from a native GUI. All "controls" are drawn of the screen
>> using DirectX and all well known input events are DirectInput calls. All
>> objects in WPF world inherit from a DispatcherObject associated with a
>> Dispatcher. The Dispatcher is responsible of queuing, filtering
>> redundant calls or prioritising requests.
>
> Yeah, I suspected that. But creating a new platform independent GUI  
> library from scratch is an enormous task. I was thinking building on top  
> of the native ones that already exist.
>

Indeed it is a massive undertaking, but platform independence is KEY to  
making this work for D because D itself is platform independent. Building  
on-top of native kits comes with it's own complexities too. So kits have  
things that others don't, so you end up with a very small set of available  
widgets, AND no way to make new ones, short of huge amounts of custom  
coding. You also run into layout problems as you can specify a single size  
for all widgets, they have different paddings and margins so the UI never  
looks right outside of the UI system the software was designed on (for  
example the KDE widgets are very different sizes from GNOME).

The beauty of WPF/Silverlight/WinRT XAML, is that it looks the same no  
matter where you're running. I understand that there are purists out there  
who believe that you should always use the OS widgets, but in today's  
fractured environments, it's just not realistic from a UI design  
perspective anymore.

XAML-type systems have the same thing in common with HTML/CSS that  
EVERYONE loves right now, with a little bit of design effort, they can  
automatically reflow themselves for any device. Like it or not, the OS  
widgets are a hold over from the pre-mobile era. How many people actually  
use the default OS widget skin for HTML buttons?

-- 
Using Opera's mail client: http://www.opera.com/mail/