--------------enig4D5DC5759FA280E4AF9D5360
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Suraj said:
I don't know why people hate it so much. They seem to prefer "desktop=20
integration" and eye-candy instead of clean, functional interfaces.=20
Sigh. :-(
=20
Some of us have to "sell" software, at least to managers - then it matter=
s.
[Hide the women, children and livestock. This just got bloody as I
predicted.]
Also, you're missing the point. It's a GUI, noone really gives a damn if
the programmer had an easier time coding it if there's hundreds of users
that will feel constantly alienated by it because of some detail the
programmer didn't feel like bothering with.
User interface design isn't the same as programming a user interface.
Programmers, especially the lazy sort, tend to suck, suck-oh-so-horribly
at user interface design. Approaching user interface design with a
programmer's mindset can only end in pain, tragedy, and Tk.
Also, you're confusing internal UI consistency, and external UI
consistency. Internal UI consistency is when the features of the UI fit
together to make working with the software alone productive (your clean
and functional).
External consistency is when the UI incorporates features that make
working with that software in connection with other software on the
computer productive. This means panels will scroll when the mouse is
over them and won't require clicking on the buttons. This means that the
file chooser, on XP, will have a "My Documents" button as the third one
in a button sidepanel on the left. (I can't describe the rage I feel
when a toolkit opens a file chooser that doesn't even try to look alike
and leaves me flailing about trying to find my way back home.) I've seen
Tk interfaces fail at all the above when they're capabilities the damn
system below them gets right out of the box, and I've no doubt that's
barely the tip of the iceberg.
Both internal and external consistency are, for pretty much most
applications, factors that contribute to productivity. Having an
externally consistent program in no way excludes it being internally
consistent, so no point in setting up that straw man.
Any GUI toolkit will let you achieve internal consistency, and getting
really good usability from a GUI is 1% toolkit choice, 99% blood and
sweat. (My favourite GUI programs in terms of UI usability, and
consequently the ones I use most are firstly Opera, written in nothing
publically known for Windows, Qt3 for Linux, and IntelliJ IDEA, based on
the by-default-horrid Swing it makes sing and dance.) However, the
mindset of most Tk users seems to be to fight achieving external
consistency kicking and screaming and inventing nonarguments to prove
such patent nonsense as external consistence being undesirable. (That's
usually laziness, youthful zealotry, incompetence, or short time budget
speaking. Prove me wrong.)
Also, to set you right. People, or at least I (the only part of "people"
I can confidently speak for - for what part were you speaking and with
how much confidence when you used the words "people" and "they" again? -
obviously not yourself), don't just prefer eye candy. I want usable
interfaces that do what I need, do what I want, and do even what I
didn't know I wanted, and pay close attention now, that *also* look
good, look native-or-better (Java 6 giving me subpixel font AA on
Windows 2000 machines at work or under uncooperative Linux window
managers), act native-or-better (cf. some Windows programs that emulate
"scroll widget under cursor"). Both. And. No. Less. I am willing to and
have paid money to get that, and when forced to make a choice, there
will be something pissing me off with either alternative making me
wrestle lossage of some sort.
(PS: Just writing desktop integration in quotes doesn't make it of no
value. Refer to the missing the point by leagues bit above.)
Oh, and to make my position fully clear, I do hate Tk as a programmer
too. I find Qt linearly superior because of the object-oriented design,
MVC support, and the mixin architecture for separating UI and controller
logic, and QMetaObject::connectSlotsByName very reliably killing event
handler wireup boilerplate. And who really cares how you lay out the
widgets when there's Designer (the form designer that made me stop
hating form designers) to do that. Oh, and even with those features,
it's probably faster than Tk.
Tk isn't hardly the Ruby of GUI toolkits, with the massive advocating of
/ tolerance to mediocrity of results, it's the PHP of GUI toolkits.
David Vallner
No Way Someone Reads This Whole
--------------enig4D5DC5759FA280E4AF9D5360
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
iD8DBQFFhL/Sy6MhrS8astoRAlcVAJ4gETBdB1lbX0HZoJHeiGf1VBXBAwCeP7yI
5vJoWH1F1CMhpSbf5MpveOo=
=hSWK
-----END PGP SIGNATURE-----
--------------enig4D5DC5759FA280E4AF9D5360--
