[Pythonmac-SIG] PackageManager link broken?

[Kevin Ollivier]

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