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