Ideal D GUI Toolkit

Adam Wilson flyboynw at gmail.com
Mon May 20 13:49:28 PDT 2013


On Mon, 20 May 2013 12:52:39 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe at semitwist.com> wrote:

> On Mon, 20 May 2013 12:28:09 -0700
> "Adam Wilson" <flyboynw at gmail.com> wrote:
>
>> On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky
>> <SeeWebsiteToContactMe at semitwist.com> wrote:
>>
>> > On Mon, 20 May 2013 11:01:35 -0700
>> > "Adam Wilson" <flyboynw at gmail.com> wrote:
>> >>
>> >> Graphics programmers who can make GPU's sing,
>> > [...]
>> >> UI designers capable of replicating the looks [REPLYER'S EDIT: "and
>> >> feel"] of each OS.
>> >>
>> >
>> > Embrace native and those two concerns disappear.
>> >
>> > And that latter of those two is *NEVER* going to be pulled off
>> > successfully with a non-native toolkit anyway.
>> >
>>
>> Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and
>> WPF (retained mode GPU rendering) are pixel identical. Only way to
>> tell the difference is if it doesn't use the default (native)
>> styling. Nick, I work exclusively in WPF/XAML all day every day at
>> work, but the last app I wrote was WinForms, what's your experience?
>>
>
> WPF/XAML is first-party, therefore it's native by definition
> regardless of whether or not it internally hands off to the older UI
> code. Saying WPF isn't native is like saying that Quartz isn't native
> just because it doesn't use...uhh, whatever the UI was called in Mac OS
> 9.
>

It's first party only insofar as it's Microsoft, but that's where it ends.  
WPF is DevDiv, Win32 (i.e. WinForms) is WinDiv, being completely separate  
divisions at a company like MS means they might as well be separate  
companies. And your Mac OS 9 analogy would be correct about the  
Win32/WinRT differences, but not WPF. WPF exists completely outside the  
scope of the OS.

> Besides, having access to all of MS's internal code, documents,
> probably even some of the original developers still around, etc., is
> naturally going to change the feasibility in a way that no third party
> toolkit (which is exactly what we're talking about here) is
> realistically going to be able to match.
>

And my point is that your assertion that it can never be done is patently  
untrue. If MS can do it, there is no technical barrier to FOSS doing it,  
other than our own mental conception of what we are capable of. The point  
about WPF is that the system is so flexible in it's rendering that you can  
precisely emulate any native OS toolkit, or go off in a completely new  
direction. I prefer that flexibility as a UI designer.

> In other words, despite your antagonism, I was implicitly **agreeing**
> with your assertion that it's one a hell of an undertaking,
> *especially* if you don't make use of native APIs under-the-hood.
>

Now that I think we all agree on. It is hard, but I think it might  
actually be more difficult to create a unified (standard) library on top  
of the native toolkits for each OS supported in Phobos. The OS  
requirements for a rendered UI such as WPF are actually far fewer,  
basically just a direct connection to the GPU and a windowing mechanism,  
virtually every OS provides those, for example, OpenGL and X. Therefore  
building the amount of shim building required is MUCH smaller.

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


More information about the Digitalmars-d mailing list