Ideal D GUI Toolkit

[Adam Wilson]

On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe at semitwist.com> wrote:

> On Mon, 20 May 2013 13:49:28 -0700
> "Adam Wilson" <flyboynw at gmail.com> wrote:
>>
>> 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.
>>
>
> I still have a hard time believing that it's realistic for it take take
> everything into account. *Even* if you go to all the effort to make
> every render and behavior pixel-perfect, you're *still* failing to
> account for all of the following things, all of which actually *exist*:
>
> - Software to allow the user to custom-reskin the system. Yes, even on
>   Windows this exists, and has for a looong time. Getting a third-party
>   GUI toolkit compatible with this would likely be quite difficult, if
>   even possible.
>

What if as a UI designer I know that I want to specifically disallow  
skinning? It's not even that hard of a decision to reach. If the skinning  
changes the layout metrics at all (margin, padding, size, even shape), my  
app can end up looking terrible and I have to take a support call for a  
case that I couldn't have possibly dreamed up.

> - On windows, I use a program called KatMouse that allows me to scroll
>   any control by just pointing at it and using my mouse's scroll-wheel.
>   No need to manually "focus" the control before the retarded Win system
>   allows me to scroll it. This is literally my #1 favorite windows
>   program. But this obviously doesn't work on programs that merely
>   *emulate* the system's look-and-feel, no matter how meticulous the
>   emulation. Hell, even the UI changes in "native" MS-developed Vista
>   and Win7 break it at least half the time.
>

I'd say it's on the developers of KatMouse to get their crap together. It  
sounds like their development model is "don't upgrade from WinXP because  
we like that one." By saying that even the MS native changes break it,  
you've kind of invalidated your point. You are telling me that's it not  
really a UI problem but a problem with the tool. Yes, this would be  
completely non-functional in WPF and similar. But I'd stand by the  
statement that it is imprudent to support extreme corner cases. You may  
like it, by I've never even heard of it, and my guess is that almost  
nobody else has either.

> - Tools to reveal the value behind "******"-filled password boxes.
>   Sounds like a black-hat tool, but I've personally had legitimate
>   need to use it.
>

Ehrm, TBH, I consider breaking those tools a good thing. Yes there may be  
legitimate uses, but the number if illegitimate uses far exceeds the  
benefit.

> - Anything else that involves either GUI-introspection or adding a
>   cross-application UI feature. There's plenty of other
>   entirely valid use-cases.
>

What is the use case for GUI introspection?

> Unless I'm mistaken, these sorts of things *cannot* be handled by a
> non-native UI without either the given utility special-casing every
> specific UI toolkit out there, or the UI toolkit (somehow)
> special-casing every such tool/utility. Neither approach is scalable
> enough to be a real solution. Ultimately, there must be *some* common
> system-wide UI, without cheaters, so that cross-cutting features are
> *realistically* possible and not inherently unreliable.
>
> Of course, you could say that such uses aren't important, but I'd very
> strongly disagree.
>

Manipulating a UI from another process is bad, evil, and a massive  
security problem, I'd say that disallowing it is a service to the world.

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