[Pythonmac-SIG] coding preference

[Jack Jansen]

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, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman