WPFfor d

[Adam Wilson]

On Mon, 18 Feb 2013 12:34:20 -0800, Jacob Carlborg <doob at me.com> wrote:

> On 2013-02-18 21:10, Adam Wilson wrote:
>
>> 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).
>
> I haven't run into any problems with different sizes of widgets using  
> DWT/SWT. Do you think DWT/SWT just lay out widgets with standard  
> behavior? The code contains a huge amount of configuration to make the  
> widgets behave the same on all platforms. Setting values, overriding  
> rendering functions an so on.
>
> Of course you can make new ones. Perhaps not as easy. But I see no  
> reason why you couldn't add a layer on top make it just as easy.
>

Define "not as easy"? I can restyle a List in WPF so completely that you  
can't even tell it's a list in about 1/2 hour. Sure the list may not look  
much like a list but it functions like one and looks the way that makes  
most sense for it's usage. I have NEVER met an OS toolkit that could come  
close to doing such major restyling so quickly. I'd have to build a new  
widget from the ground up. QML can ... but it's also not an OS widget  
toolkit either. QML also proves that it isn't just MS that thinks this is  
a good thing...

> The custom tool kits always invent their own ways of doing things,  
> breaking with the rest of the OS. The user then just gets confused when  
> one thing works in one application but not in the other.
>

I have yet to encounter this fabled user confusion during usability  
testing, so I am gonna file this one under "myth".

>> 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.
>
> It only runs on Windows.
>

That has more to do with the fact that MS made it than any technical  
limitation.

>> 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?
>
> If you want to build serious applications that take full advantage of  
> the platform, that never works. Just look at iPhone and iPad, they have  
> different widgets even though they're so similar.
>

It does with a Silverlight type toolkit. The iPhone/iPad widget situation  
demonstrates part of the problem with OS widgets. They are tied  
intrinsically to the platform, I am trying to free myself from having to  
have multiple UI layouts for each platform. My point about fracturing is  
that the same app can have completely different layouts from iPhone to  
Android, all enforced by the OS. You don't honestly think thats a good  
thing for cross-platform usability ... ? Sure, much of the difference has  
more to do with Apple being dicks in the courtroom but as a third party  
that doesn't provide any one style, they can't really make a legal case  
against it. It's not like I am trying to copy their style or anything...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/