On Mon, 18 Feb 2013 01:33:51 -0800, Jacob Carlborg <d...@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/
