On 22-jan-05, at 2:21, Kevin Ollivier wrote:
Hi Jack,
Hi Kevin!
First: sorry for my bad choice of words. "throwaway apps" especially is not what I should have said, and some of the other words were badly chosen too. I definitely don't want to belittle the work you're doing with wxPython (and other people with other toolkits), far from it!
I think you're getting bogged down by the differences between platforms rather than abstracting them. ;-) Which is what any cross-platform developer will need to do if they wish to succeed, regardless of what GUI toolkit(s) they use. For the most part, it isn't 'what' the native toolkits (or platforms) do that differ, it's 'how' they do it. So if you program 'what' you want to do, and design the toolkit to figure out 'how' to do it correctly on each platform, a lot of times you can get the right look *and* feel without much extra effort. Granted, there are some technical challenges (look at Apple's Carbon text control technologies, like MLTE for example, where sometimes you need to manually implement even basic, standard functionality), but I have a hard time understanding how these difficulties are insurmountable.
I guess my real point is that once you abstract that far enough you're at the MVC level. To name just a few paradigms that differ between Mac and Windows:
- Standard menu structure and shortcuts, i.e. where the Preferences command is, whether it's called Preferences or Settings and its shortcut, the Windows menu, Help, etc. are completely different.
- Treatment of toolbars. Windows users like oodles of them, Mac users are used to one. Windows programs often have them filled with dropdown menus, etc.
- Mac preferences tend to be direct manipulation, windows preferences tend to be cancel/ok/apply style.
- Mac programs tend to require every command to be available somewhere in the menu bar, with toolbar/contextual menu entries used as shortcuts only. No such rules on Windows.
- Two-paned browsers are ubiquitous on Windows. On the Mac they look otherworldly.
- The Mac floating palette style is cumbersome on Windows (cf. all Adobe software), and the Windows MDI architecture translates very badly to the Mac: window-in-a-window is abysmal, but multiple toplevel windows is bad too because there often tend to be really many of them. Tabbed windows for, say, editing multiple source files is the norm on Windows (probably because of MDI or the Visual Studio example) but makes Mac users scream.
By the time you've special-cased all of these there's not all that much machine-independent code left:-(
Well, that depends on the programmer. Even a Mac developer can create an application that doesn't "feel" like a Mac application; it really isn't very hard if you try. (And for people coming from Windows, that will be their natural inclination anyways.) It's arguable that the problem is the toolkit at all - it's the developer simply not taking Mac design considerations into effect. Yes, toolkit affects their ability to do this, but in the end a tool is just a tool. I see no fundamentally technical reason a cross-platform GUI toolkit *cannot* provide a user with the ability to create a well-designed Mac application.
Right, but where a local toolkit will get a lot of things right automatically (or because the skeleton programs already do a lot of the right things) with a cross-platform toolkit you'll have to be aware of the issues...
Just be aware that for all but 'throwaway' apps, this means that some developer is going to have to learn and master three different GUI toolkits, and create, test, debug, document, and package three totally different interfaces. Maybe you have time to put in the extra effort when writing your apps, but I think a lot of people don't. And when a PHB is told that the only way to support a minority platform is to do that work, s/he's going to say - sorry, just build the Windows version. For my app, I can tell you without doubt - if I had to do what you suggest, Mac support would not be an option. Bye bye Mac port.
Well... for a commercial app you'll have to do the testing, debugging and packaging anyway. So you'll save on creating and documenting. With only a little on the latter: Adobe and Macromedia (and my previous company, Oratrix) did the multiplatform documentation by putting in one section on the mac (installation and first run) and using a mac screenshot once in every 5 or so. And then one proofread adding a couple of paragraphs.
I performed some training last summer, and to be honest, the Mac users at the training were quite glad that a Mac version of my app existed and that they weren't marginalized users (as they often end up being in the real world) who would need to "pick up a PC" to undergo the training. It certainly wasn't as 'slick' as an Apple app, but it worked and some people quite liked it. And in the end, that's how I personally measure whether a technology is "good" or not. Whether or not it has a positive impact.
Fully agreed. I guess that where I said "throwaway app" I should have said "applications that provide a unique service that isn't available anywhere else". Whether that unique service is for you yourself only (as in a throwaway app) or for a larger community isn't the point.
But if your app is competing with other products (an IDE, an image editing program, a database or spreadsheet, whatever) it will really have to stand out in functionality to offset the disadvantages of a cross-platform toolkit.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
