Gui Advice Needed: wxPython or PyQT ?
Alex Martelli
aleax at aleax.it
Wed May 7 13:12:30 EDT 2003
Kevin Altis wrote:
> You're right of course. Qt probably works fine and I have no way of
> effectively judging a particular app I've never seen so I should just shut
> up.
Judging a framework is even harder than judging an app, IMHO -- and a
cross-platform GUI framework hardest (e.g., having no Mac at hand, how
do I get ANY idea of how well a given GUI framework lets a non-Mac-
savvy programmer port their apps to the Mac...?). Fortunately we did
get a testimonial post from somebody with experience porting the SAME
app from wx to qt -- a rare thing. However, honesty compels me to point
out that even that paean is just one datapoint - not just because each
developer will have different preferences, but also because inevitably
one ends up trying one framework after the other... and this can cut
both ways (habit might have built up for the first framework and thus
bias in its favor -- but conversely, during the port one knows the app
better than during its first development, and the enhancements one can
thus make might end up unfairly credited to the second framework used,
subconsciously and at least in part...).
> It looks like Photoshop Album
> http://www.adobe.com/products/photoshopalbum/
> replaces PhotoDeluxe which had a very non-standard UI, but it was still
> usable.
Interesting! I didn't know that and I'm not familiar with either app.
I do find that often the usability (for me) of an app's GUI has relatively
little to do with its using the platform's native look and feel, and much
more to do with general design issues -- how well or badly does the GUI
reflect the mental model of the application that I, as the app's user,
build up and use to guide my work.
> But that brings up another good point of why native widgets look and feel
> may no longer be crucial. After almost 20 years of consumer GUI usage from
> when the Mac (does the Lisa count in the consumer space?) was introduced
I think it doesn't (it wasn't targeted to consumers).
> in 1984 users have gotten very sophisticated. The diversity of UI elements
> inside the web browser and videogames has changed user expectations. You
> still have buttons, fields, and lists, etc. but they all look different
> and sometimes behave slightly differently than native widgets. Even the
> hyperlink, where a simple font, color change, and/or bold/underline sets
> the link apart from normal text is a big leap. In addition, themes have
> changed the look of controls, but behaviors with themes stay the same.
Yes, very good point. Even though some usability experts are on a permanent
crusade to make all websites look the same, in the name of user familiarity
and comfort, reality's still very different (with both good and bad
aspects to that difference). Anyway, studies made and experiences built
up back when GUIs in general were totally new experiences to most users
need to be taken with a grain of salt nowadays. Perhaps usability, to some
extent, has come to depend more on intrinsic quality of the design and
less on sheer familiarity (though the latter no doubt still matters too).
But the "familiarity" and the "compliant with current platform fashions"
aspect also disagree often. I'm still familiar with menus that stay the
same from one run to the next - but on a major platform, all the rage is
with menus that "learn" and adjust to hide choices I never make and put
the frequent ones handier. In theory I see the point, in practice I just
HATE the experience -- perhaps because I'm atypical in using several
machines, and having the same app with very different menus on different
boxes is just too horrid for words. I'm not even sure I'm all THAT
atypical -- I see lots of "internet cafes" with rows of machines often
used by many people, machines in airports and hotel lobbies and malls,
a LOT of users commonly doing similar tasks on at least one machine at
work, at least one at home, plus an average of close to one laptop...
> So, maybe only user testing can tell you if your particular UI does or
> doesn't work? It may also be that expectations of how window frames and
> menus on a given platform are more strict, but that the UI elements inside
> the window can have a look and feel that is different than native widgets.
> This would be a good research topic.
There would seem to be potentially a lot of money in it, as well as a
lot of money being needed to conduct such research, given that you'd
need vast amounts of human subjects.
> Anyway, I'm more interested now in the other issues with Qt, not so much
I think the #1 issue (and maybe the only significant one) with Qt for most
people is its complicated, and potentially costly or bothersome, licensing.
If you're in sharp situations -- a commercial software house choosing what
to use for your programming (in which case a few thousand dollars may be no
big deal given all the other expenses each of your programmer employees
must incur for you, salary foremost:-), or at the other extreme a developed
committed to doing GPL development for free OS's only -- it's not too bad --
you purchase professional or enterprise licenses as needed, or on the other
hand choose the GPL or QPL licenses, and off you go.
If you're in a situation that's not as sharp and well-defined as these
then the complications do start. E.g. for windows there's a non-commercial
license and an educational license and others yet -- and I don't know the
details, the costs, and so on. PyQt has its own licensing on top of Qt's,
so you have to consider that, AND the Blackadder's possibilities too (not
trivial, if you use Python for all of your Qt development and not C++,
then BA's licensing can save you a bundle compared to Qt's + PyQt's). I
am *NOT* surprised that people get confused and turned off as these issues
and prefer to look for the simple Python-like license of wxPython!
> with the native look and feel, which in the past was the reason I always
> ignored it. Thanks for getting me to think more about this.
You're welcome, and thanks in turn for stimulating my own thinking and
expression on the subject. I've also been moved to upgrade my Blackadder
install to the recently released beta4 and am discovering quite a few
unpleasant incompatibilities wrt my trusty Mandrake 9.0 (Mandrake CLAIM
they've at long last shipped me my 9.1 powerpack, but, no sign of it in
my mailbox yet...), all the way to apparently needing an NVIDIA special
kernel (!), it seems due to the fact that BA beta4's RPMs may have been
built on a machine using NVIDIA (and then some wonder why I hate and
abhor RPM's and ALWAYS prefer to install from sources when feasible...!-).
So right now I'm rebuilding qt, SIP and PyQt from the latest version's
sources of each to try and compensate for the damage wrecked by the
rpm install (with force and ignore-dependencies, eeccch...) and then
I'll turn back to checking what if anything i can do about using BA
once more...;-).
[the wx's world isn't all wine and roses either -- I tried to install
PythonCard on this same Linux box but ended up giving up -- too much
of a hassle, too many dependencies &c -- bottom line, despite the brave
new world of RPM's and deb's and so on, installing big, structured and
complicated packages on Linux sometimes IS still a big bother:-)]
Alex
More information about the Python-list
mailing list