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
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
