[Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac?

[Bob Ippolito]

On May 24, 2005, at 7:08 AM, Karl Merkley wrote:

>
> On May 23, 2005, at 9:42 PM, Kenneth McDonald wrote:
>
>
>> This is only half a Mac question, I admit, but the Mac aspect will be
>> a big influence...
>>
>> I'd like to pick a crossplatform UI library for which Python has
>> bindings, to start doing some programming in. I've used and liked  
>> Tk a
>> lot in the past, but unfortunately it seems to be (1) way out
>> popularity, (2) not moving forward in any significant sense, and (3),
>> in my experience, often quite difficult to use on the Mac with Python
>> and other Tk addons, due to compile issues.
>>
>> The flavors o' the day seem to be either QT or wxWindows. So,
>> questions:
>>
>> 1) Is either of these difficult to install or use with Python on the
>> Mac, using a version of Python newer than that which shipped with
>> Tiger? If one is easier, which one?
>>
>> 2) Similarly, for which is it easier to get third-party widgets and
>> libs up and running, under the conditions stated above.
>>
>> 3) Finally, since I'm asking, a non-Mac question; which do people
>> think is better, both in the context of using with Python, and in the
>> more general context of being a good UI lib.
>>
>>
>
> Just to give the other side of the issue . . . I don't do a lot of  
> PyQt
> but for the instances that I have it has always worked great.  I do a
> LOT of Qt in a C++ environment across a wide range of platforms (Mac,
> Windows*, Linux, IRIX, HPUX, Solaris,  32 and 64 bit OS's).
>
> I don't have any problems with the build environment.  Qmake takes a
> tiny bit of learning but it's not bad.  I am actually using CMake for
> the cross platform build environment for a very large project (>1M
> lines with multiple 3rd party libraries)  because it was a little more
> powerful/flexible.

I was really referring to the fact that Qt has all sorts of screwed  
up things in their own build process for Mac OS X (Qmake aside), so  
you end up having to tweak environment variables that you should  
*NEVER EVER TOUCH* (dyld stuff) and you end up with software that has  
incorrect dylib paths in it (unless cleaned up with install_name_tool  
manually or with macho_standalone / py2app).

PyQt (SIP really) also does a lot of really bizarre things it  
shouldn't do, and puts WAY too much code behind the scenes in C (even  
inter-module dependencies), so it's not possible for py2app, py2exe,  
etc. to correctly analyze this code.  py2app says "oh well, they're  
using SIP, let's include ALL sip modules" so you end up with huge  
applications that you have to prune by hand.  py2exe doesn't know  
anything about the issue so you end up with non-working applications  
and you have to keep adding PyQt bits until it works.  cx_Freeze  
includes even less library-specific code than py2exe does, so I  
imagine it's much the same there too.

Since they can't get their library linked correctly, I don't see how  
they can be trusted to offer a stable as-native-as-possible cross- 
platform environment for Mac OS X.  Having tried it out -- they  
can't.  wxWidgets doesn't quite deliver on that yet either, but  
they're much farther along and you don't get hit with license fees or  
stuck with the GPL if you use it.


> Licensing can be a concern but I got my customer to pay for commercial
> Qt and PyQt licenses.  My customer is happy with the work that I do  
> and
> I give them the tools they ask for more rapidly than I could with  
> other
> GUI development packages (IMHO of course).  I am happy to pay some
> money to keep a useful tool alive since I am making a living by using
> the tool.

I'd love to pay license fees for when I need something that works  
well enough everywhere, but such a product doesn't exist yet (when  
"everywhere" includes Mac OS X).  Except maybe REALbasic -- but then  
you have a different problem.

> I made my initial decision about three years ago.  At that time I felt
> Qt was by far the stronger library and I have not been disappointed
> with that decision.

Three years ago it didn't work at all on Mac OS X, unless you could  
the X11 version, which you shouldn't.

I'm not sure I'd say it completely "works" on Mac OS X even today.  I  
did say, specifically, that I highly recommend ignoring Qt *on the  
Mac*.  It works fine, even great in many cases, on other platforms...  
but this is pythonmac-sig, python-list, so presumably the person  
asking the question wants to make applications that work well on the  
Mac (and they did say "the Mac aspect will have a big influence").

-bob