[Pythonmac-SIG] Mac User Python newbies

[Bob Ippolito]

On Feb 9, 2005, at 13:14, Chris Barker wrote:

> Bob Ippolito wrote:
>
>> In our case, it was roughly 10x easier to hit the Mac platform first.
>
> Wow! That is a BIG ratio...really?

Yeah, Cocoa already did all the view stuff and it took no time at all 
to lay it out in Interface Builder.  The domain specific stuff was 
easier too, but not by as much.

>> The Tkinter GUI and the PyObjC GUI share a bunch of code (as much as 
>> is reasonable).
>
> Ah, that explains it.
>
>> The Tkinter GUI actually has code in it to emulate a bunch of 
>> Mac-isms and it reads resources directly out of its sibling Mac OS X 
>> bundle (metadata, localization, and the application's data).
>
> And that explains it more. You ended up writing your own X-platform 
> toolkit.

Sharing the localization support was just common sense and was trivial 
to write.  It was all coming from excel spreadsheets originally anyway, 
and it was trivial to use Apple's ".strings" format.  The way you said 
it sounds way more complicated than it actually was.  None of the view 
code is shared, if that's what you're thinking.

Sharing the data was going to be an application specific problem any 
which way, so I don't think that's relevant.

>>  I'd have used wx, but Tkinter was easier for this
>
> It doesn't sound like it to me.
>
> Anyway, I think it is much harder to make a version on one platform, 
> and then port it to another, than it is to make it cross-platform from 
> the beginning. This was Joel's point: once you have a Windows version, 
> making a Mac version is unlikely to be cheap enough to do. In your 
> case, it worked, because the Windows market is about 10X as big as the 
> Mac market, so it was worth spending 10X the effort.
>
> If you had used wx from the beginning, I suspect the whole process 
> would have been cheaper, you could have improved wx, rather than 
> writing a Cocoa emulation layer for Tk. Of course, wx would have to 
> have been at least as good as it is now for OS-X, which it has only 
> been recently. Perhaps you couldn't have gotten the full Mac 
> experience right either, but it sounds like at the moment, you don't 
> have the full Windows experience, which may matter less, Windows users 
> being what they are.

For this application, the Windows problems are entirely in the 
application domain and have nothing at all to do with the windowing 
toolkit.  The only thing "non-windows-like" is that it doesn't have an 
installer, it's just an exe file that sits next to the Mac .app folder 
and requires no installation.

In this case, I had no interest in improving wx for Mac, I knew I could 
get it done properly and very quickly going straight to Cocoa.  I 
didn't want to waste any time, as it was important to get it out there 
quickly.  Also, using wxWindows would've added at least another 2 megs 
to the compressed download size of our application on the Mac side, 
which would've been marginally acceptable, but certainly not desirable.

> By the way, I say this from the perspective of a house that has been 
> developing Mac + Windows software for a while. Most of it is written 
> in C++, with the Mac as the primary platform, and Windows as the 
> second. We have an in-house cross-platform layer, that is essentially 
> a Mac emulation layer for Windows. The result is a lot of work, and 
> applications that don't really look right on Windows. More recently, 
> we developed an app with CodeWarrior PowerPlant on the Mac, and MFC on 
> Windows. We ended up with an app that is very native on both 
> platforms, but it took a heck of a lot of work. The Model is shared, 
> but the GUIs are completely independent, and took almost twice as long 
> as a result.

Cocoa is a LOT easier to use than PowerPlant is..

-bob