On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky
<seewebsitetocontac...@semitwist.com> wrote:
On Mon, 20 May 2013 13:49:28 -0700
"Adam Wilson" <flybo...@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/
