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

[Karl Merkley]

On May 24, 2005, at 9:21 AM, Bob Ippolito wrote:

>
> 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").
>

All I can say is that I ported my very large, very complex app to the 
Mac during the last 6 month release cycle.  Qt was the least of my 
worries.   Everything worked great with a single code base on all my 
platforms.  I did run into one problem with custom cursors and I had to 
disable them on the Mac.  A bummer but not a killer.    Yes, I did have 
to do my own packaging using the installl_name_tool.  I had to build a 
script to build the bundle for me.  But I have so many component 
libraries and frameworks that I wanted to make sure that I know exactly 
what is going on anyway.

BTW, I embed python in my app and I do it in the same method on all 
platforms and I do not use py2app to help me with that process.   I 
have been interested in your comments on that but as I have not had any 
problems as of yet I haven't worried about it and the method that I am 
using works regardless of platform.

       Karl