Subject: Re: PackageManager link broken? - msg#00260

Previous Message by Date: click to view message preview

ANN: pythonmac.org

I went ahead and put up a quick page with links and MoinMoin. See http://pythonmac.org/ and http://pythonmac.org/wiki/ Let me know if I'm missing anything important. Please no design suggestions yet, I have friend that's going to be branding it shortly. -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig

Next Message by Date: click to view message preview

Re: bundlebuilder --standalone not working

"Bob Swerdlow" <rswerdlow@xxxxxxxxxxxxx> writes: > Thanks, Jack - I didn't know about sys.executable - it's not in Python in a > Nutshell (for Python 2.2). Is this new in 2.3? Hardly. Might have been new in 1.3, or something like that :-) Cheers, mwh -- I have *both* hands clapping, but I'm still not sure it's a sound. When I tried deciding if it were a sound while clapping only one hand, I fell off my chair. -- Peter Hansen, Zen master, comp.lang.python _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig

Previous Message by Thread: click to view message preview

Re: PackageManager link broken?

On Wednesday, September 24, 2003, at 12:49 PM, Bob Ippolito wrote: << snip to keep this from getting too long>> But this is exactly what wxPython is designed for. It's not just so that it works everywhere, but so that it works everywhere in the manner that users of that platform would expect. The wxPython version should act like Mac users expect it to act on Mac, like Windows users expect it to act on Windows, and like X11/GTK/Motif/etc. users expect it to act. If wxPython isn't doing this, then there are things about wxPython that need fixing, and we'd like to hear about them. =) There's little visual bugs at the wxMac level, as I'm sure you're well aware of.. Those tend to burn the eyes of Mac users. I know this is the goal of wxPython, but it's just not there yet and we're talking about an application that should be written and deployed in the near future. True, but we're discussing the interface for PackageManager, so fixing the specific UI glitches it has wouldn't likely be a major effort and would help wxMac as a whole. I'd like to do this *even if* PyObjC is chosen for the PackageManager GUI. As a side note, are there special services/behaviors that are specifically Cocoa-only and that would benefit PackageManager? From what I've seen (i.e. I looked at making Safari accessible from wxMac) it seems as if Cocoa libraries could be made accessible to C++/Carbon, quite easily in Safari's case. Basically the deal is that Carbon and Cocoa can do the same things, but Carbon is the explicit way of doing everything and Cocoa is the easy way of doing everything.. For example, Cocoa apps all know how to use Services, it's easy to make a Cocoa app scriptable (via Apple Events), etc. It's possible to do all these things from Carbon, but you will not have any fun implementing it. A curses Package Manager would also be great (a la dselect), on top of, of course, a command line utility for querying/installing packages. I think there's too much impedance mismatch on how Mac, Win32, X11, and ssh users like their applications to work to use the same UI for all three. Especially for the ssh users :) Maybe Win32 and X11 users would be happy with using the same Tkinter or wxPython GUI, but I think that Mac users tend to much prefer UIs designed for the Mac. But that's making an implicit assumption that you need to use PyObjC to design a UI "for Mac". wxPackageManager was designed for Mac specifically, though I would agree it could be improved (especially since it's a prototype - I was trying to get ideas/feedback on it). If it is not Mac-like in some manners, please let me know what they are so that I can look into getting them fixed. I would like all of my interfaces to be as optimized for Mac folks as possible, considering that I am one! =) I'm not saying PyObjC is the only way, but it is by far the most fun to develop for and is very quick. Interface Builder is king. Yes, but we're talking about what the developer needs (or wants) now... ;-) In any case, a wxPackageManager is already built and can be used with some tweaks. I do have to check out PyObjC for comparison, even though my primary target audience is Windows users and thus I won't be able to use it. I agree though that a command line version would be great. =) I enjoy PyObjC development and wouldn't mind writing a PyObjC equivalent to Package Manager.. it wouldn't be very big or hard to maintain, and it would have the added benefit of being intuitive for a user of other Cocoa applications. Another thing is that a PyObjC application of about the same complexity as wxPackageManager takes about 3 seconds to start (bounces right up until the UI shows) where wxPackageManager takes about 10 seconds to start (bounces twice, then just sits there with no UI for 8 or 9 seconds). wxPackageManager also does not respond to cmd-Q, but I'm sure that's fixable? Part of the issue here is that I believe the current wxPython is running against debug versions of the wxWindows libraries, which is likely affecting startup time somewhat. I've sent a note to Robin Dunn about switching to release versions now that the port has been out a while. (They're already moving into the 2.5.x unstable port, which will probably use debug libraries.) I don't know how much this will help, but I will certainly look into it. But the difference between 3 and 10 seconds is a WHOLE LOT to blame on debug libraries. What the heck could it possibly be doing during that time? That's a whole lot of cycles to go around! I wasn't blaming it all on debug libraries (I was careful to state 'part' of the issue)... Obviously as a UI wrapper wxPython adds some cycles to the whole process, and it can't all be trimmed. It also runs on Windows. My point was that maybe switching from debug to release could cut some of that time and make the loading time more reasonable. There's also an initiative to trim the libraries down so that only what you need is loaded, but I don't know if that will make it into wxPython. Also, thanks for pointing out the cmd-Q thing, it is fixable but it might need to be fixed in wxMac because it requires access to the application menu. It still leaves it in the File menu for Classic support, but I think this week they're branching for classic and moving to Carbon-only development. In any case, I can see about getting this into the next release of wxPython. (I'll also double-check that the shortcut for the Preferences menu works as > well.) Another good thing about PyObjC is that it's low level enough to fix almost anything from Python without having to recompiling a really large cross-platform GUI framework ;) It is obvious that PyObjC wins the contests for being the easiest and most flexible GUI development tool for Mac, and really if someone wants to build a PyObjC PackageManager, no one is going to stop them. (And I have a feeling that Jack would of course put it into PythonMac.) I just think having one interface that works the same on all three platforms is nice because it reduces learning curve and looks consistent. It also shows that it can be done, and done well. Lastly, it also paves the way for a cross-platform IDE, a cross-platform GUI builder, etc., etc. I think this would be a great way to show people it can be done with Python, and eventually I think it could become the "toolkit" of choice for building RAD cross-platform applications. We're talking about appealing to different groups, really, but IMHO I'd like to see cross-platform tools use a cross-platform interface, and PyObjC and Mac-specific tools use a PyObjC interface. Though I feel I'm on the losing side of the battle here... ;-) Thanks, Kevin _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig

Next Message by Thread: click to view message preview

MySQL-python

Hi - I'm trying to build the MySQL-python module (v0.9.2) using the fink version of python (2.2.2) on a G4 iMac running 10.2.6 (and 10.2.8 for that matter) and I'm getting this error: line 1033, in gen_lib_options File "/sw/lib/python2.2/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: 'int' object has no attribute 'rfind' when I try to run /sw/bin/python setup.py build I've looked about on the web and posted to comp.lang.python and gotten no joy. Does anyone in pythonmac-sig land have any advice on how to get the module to build? TIA - Craig _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig