Gui Advice Needed: wxPython or PyQT ?

[Alex Martelli]

David Bolen wrote:

> Alex Martelli <aleax at aleax.it> writes:
> 
>> True: if everybody in your development shop is involved in developing
>> GUI's, this is indeed steeper.  I forgot what big savings we have by
>> having all GUI development done by a small specialized team while most
>> developers work exclusively on the middleware, backend, web stuff, &c.
>> That's how most firms I've worked in or with are organized, so I forgot
>> that such specialization is probably the exception, not the rule.
> 
> Maybe we're just unlucky that way :-) We have specialization today
> (although I'm trying to actually move further away from that with some
> XP practices), but we also have fairly distinct system components that
> have independent UIs.  For example, our embedded hardware platform,
> the main end-user product, internal tools developed for our support
> groups, and custom tools developed for business partners.  Carving the
> UI out of all components to assign to a UI team doesn't fit all that
> well, at least not to this point.

Yes, I see how one could specialize along very different routes
and end up needing many more licenses -- or follow XP's guidelines
and avoid specialization altogether.  In my experience the skills
and mindset needed to produce good user interfaces are so drastically
different from those connected with the "engines" (back-ends and
middleware) behind those UI's, that specializing along those lines
seems so very sensible to me.  That may depend on the application
field, I guess.  In any case, if your organization is specialized
along different lines AND moving AWAY from specialization, it sure
doesn't make sense to change things just because of licensing.


>> Besides, I'm clearly not current -- I _thought_ the licenses where
>> $1500 per developer, not $2000.
> 
> I should have mentioned that I was working on the enterprise edition
> (the pro is in fact around $1300/per at the 6+ mark), since we'd we'd
> need QTable (although not really the rest of enterprise).

Ah yes, QTable's very alluring (haven't used it in production, but
I see how it might well help with many kinds of applications).


>> It seems to me that the contrary applies -- a bigger shop, if there
>> is no site licensing (and always assuming no specialization), would
>> end up paying way more, in proportion.
> 
> I guess I was figuring that while in absolute terms a larger shop
> would pay more, they would have a better chance of it being a smaller
> percentage of the overall development budget and/or there would be
> better odds that only a percentage of the team would need GUI
> development.

I don't really see why.  If there's no specialization, overall budget
is going to be O(N) with the number of developers and so is the QT
license cost.  If there IS specialization along lines that require
everybody to code GUIs anyway, same thing.  If the specialization is
along the GUI/non-GUI axis, then the fraction of developers who code
GUIs will be determined by the kind of applications being developed:
how much back-end/middleware/communication/engine functionality there
is, vs how much front-end/user-interface (presumably excluding WEB
based user interfaces which should really be designed and coded by
a separate specialized team, IMHO).

There will surely be some "critical threshold" below which there can
really be no specialization -- a development shop with, say, two or
three developers, can't really afford to leave all GUI coding to just
one of them, normally.  But once we're talking about six or twelve
or sixty people, I would not expect the group's size to make all that
much of a difference.  It IS quite possible that I'm missing some
important consideration, of course -- even though I've worked in and
for very large firms as well as small ones, I've never seen effective
development groups of above a couple dozen people anyway, no matter
how large the overall organization (I've never seen, say, 100 people
working as a single group on a single set of software projects with
any effectiveness -- I'm not saying it CAN'T be done, just that I've
never experienced it happening, myself).


>> 1.0beta4 was put out very recently, and the support mailing list was
>> quite prompt in addressing my issue (although nothing happened to
>> SOLVE them, mind you:-).  But I don't understand your concerns.  By
>> signing up while it's still beta you get a DIRT-cheap license -- WAY
>> cheaper than trolltech's -- to redistribute Python-only PyQt apps;
>> why do you care if they take one month or 12 to get out of beta?  As
>> your license is valid for one year until AFTER they get out of beta
>> it would seem any delay in their doing so is to your advantage...;-).
> 
> Assuming they ever get out of beta.  My primary concern is that the
> product never reaches a release stage and ends up being stillborn, in
> which case I'm leery of committing a development team to using it for
> a new development project.  I realized there was a December Beta
> release, but I didn't get the warm fuzzies when the FAQ on the site
> doesn't seem to be updated (still talking about needing 2.0 versus 2.2
> referenced the main page, and still talking about months for the beta
> when it's been far longer than that).  Just little things here and
> there that make you go "hmmm" when evaluating, so I was curious as to
> your experience.

Heh -- stale websites are a common occurrence for many firms:-).  I
understand your concerns now, and I really have no "insider info" on
the basis of which I could reassure you -- the discussions on the BA
mailing list do seem to me to point to very active development, it's
just a BIG product for a small firm.  E.g., the direction it seems to
be going in is to keep an *external* QT Designer, rather than fully
embedding and customizing it -- that would appear to be a rather smart
technical move, for example.


Alex