On Mon, 20 May 2013 17:04:40 -0700, Nick Sabalausky
<seewebsitetocontac...@semitwist.com> wrote:
On Mon, 20 May 2013 15:50:06 -0700
"Adam Wilson" <flybo...@gmail.com> wrote:
On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky
<seewebsitetocontac...@semitwist.com> wrote:
>
> 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.
Basing software decisions upon worries of "What if some user shoots
himself and calls our support?" is *always* a bad idea.
Is it though? Because regardless of whether or not they should call me,
they will, and I will have to spend money to deal with it. Again, I have
real problems that are clashing with ideology. When that happens the
engineer in me demands that I address the real problems.
The user overrides the developer/designer. Always. The user is the
whole reason for *anything* we do in this field. The user may as well be
God - if they want to do something questionable, we can raise warnings,
but it is *absolutely* not our place to prevent it. As soon as you
start down that route, anything you do becomes a pointess waste that
defeats its own reason for existence.
Why? The user mostly doesn't care as long as it works and solves their
problem, I personally spend less and less time customizing my environments
for two-fold reasons, I have an every growing number of them, and I care
less and less, just get out of my way and let me work. Don't make me
decide on a hundred details before I can get started.
> - 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."[...]
You're missing the point:
The point is NOT that "XP -> 7 should be seamless for all software". I
don't believe that, and I would never claim it or deliberately imply it.
The point is that even the most *meticulous* and convincing native
emulation is *still* insufficient (and ultimately a big waste of time).
Should it be the responsibility of the program itself support newer
versions of Win? Obviously. (Unfortunately, KatMouse appears to
be closed-source abandonware, but that's completely beside the point.)
Should it be the responsibility of the program itself to support the
various non-native third-party GUIs just because some
self-important GUI developers didn't feel like playing ball and
decided that *their* internal conveniences were more important than
their users, the very people for whom the all this software exists
in the first place? *Absolutely not*.
You may like it, by I've never even
heard of it, and my guess is that almost nobody else has either.
popularity != importance
popularity != value
popularity != worthiness
(popularity != a goddamn thing)
It is unreasonable to expect GUI developers or GUI designers to
explicitly support various tools like KatMouse? Absolutely. It is
definitely unreasonable. And that's *exactly* why non-native GUIs are
horrible idea.
> - 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.
I strongly disagree:
First of all, there is very little, if any, illegitimate use of this
that doesn't require *at least* as significant a security breach to
have *already* occurred.
Secondly, we're not babysitters or self-appointed police here. To
engage in such a level of control is *already* a very serious breach
of our moral obligations.
In the real world, yes, we are. You see, it's a small inconvenience known
as the lawsuit. Specifically that I am legally liable for any and all
security vulnerabilities within my product. There is case-history going
back to support this since the dawn of legal systems. It is ironclad,
ideology will not change it. I consider cross-process of a UI a MAJOR
security problem because it allows malicious software to modified my
software in subtle ways that compromise the security of the system. And
apparently I am not the only one who thinks this way because every mobile
OS available today does not allow ANY kind of cross-process UI
manipulation of any kind, going so far as to sandbox each app. Where is
your outrage over Android or iOS or WinRT or Blackberry or Symbian?
> - 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?
Just for example, Spy++ or any similar such developer tool. Or GUI
macros. Those are just off the top of my head. I'm sure people can, and
have, thought of any number of other different uses.
GUI macros work on WPF apps. Snoop does what Spy++ does.
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.
I couldn't disagree more. I don't believe for a second that that's
even the slightest bit different from saying "Using a computer is bad,
evil, and a massive security problem; disallowing them is a service to
the world."
We're not Big Brother and I, for one, refuse to be party to anything
even remotely smelling as such, which is something (ie, "Big Brother")
that I very much believe your views on our responsibilities as
developers *do*, by necessity, constitute.
Have you ever built any software where you are legally liable for any
security holes your software opens up? My guess is no. Because if you had,
you'd get where I am coming from.
Ideology is fine, right up until you have to meet the real world. Do you
honestly expect your users to each become security experts? Such a thought
is laughable on the face of it. They have neither the time nor the
interest, and nor should they, it is not a productive use of their time.
This is why the law makes it MY fault for security flaws, because there is
not, and can be no, reasonable expectation that they are security experts,
that's MY job.
Ergo, allowing cross-process UI manipulation is inherently wrong, it's
also legally and ethically wrong. Putting my users at risk in the name of
ideology is so wrong that I am dry heaving at the thought. Incidentally,
this is why no mobile OS ever allows it, it's WAY to legally risky. Not
even Google can make that lawsuit go away.
Nick, I hate to break it to you, but you are so far out on the extreme end
of the scale on this one that it will be impossible to advance technology
and keep you happy, so I'll have to leave you behind, because the 99% want
there software to just work, and could care less how it does it. I don't
like leaving people behind and pissing them off, but I have to go where
the majority goes, otherwise I'm just a penniless artist with a rigid
ideology and no friends.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
