Hi Jack,
On Jan 23, 2005, at 3:16 PM, Jack Jansen wrote:
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!
Apology accepted. :)
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.
Sure, but there's a big difference between learning and programming against three toolkits (which all have their own paradigms, APIs, and bugs) and learning and programming against one toolkit that handles much of the differences for you. After all, there's no reason that MVC requires that you use three toolkits instead of one for your GUI. ;-)
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.
Most of these are easy to deal with, and wxPython does deal with Help, About, Preferences, etc.
- 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.
But are both of these Windows/Mac differences, or just differences in application design? In other words, is it because Windows users prefer oodles of toolbars, or instead, is it because most developers have never experienced a Mac program and Mac design philosophies? (Many of which aren't specific to the platform.)
In any case, customizable toolbars seem to be the solution that Mac-specific and cross-platform apps are headed towards, something wxWidgets or any other toolkit is capable of.
- 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.
Another case that I would argue has little to do with the toolkit itself. And IMHO this is also a case where this isn't Mac-specific design - it's good design. ;-)
- Two-paned browsers are ubiquitous on Windows. On the Mac they look otherworldly.
Using a Drawer or Sidebar (ala Tiger's Mail.app) achieves the same functionality in a way that works on all platforms. (If I understand what you're referring to correctly.) And in fact, Windows Explorer now uses the sidebar approach.
(And, BTW, we now have Drawer support in wxWidgets CVS too. It uses a sidebar on other OSes.)
- 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.
Really, MDI has mostly been abandoned on Windows too. MS Office and Macromedia tools now use top level windows for each document, which is actually pretty close to the Mac approach. And Adobe uses floating palettes AND MDI, so the two aren't at all mutually exclusive. I've personally found that dockable palettes work well on Windows, and have seen more and more apps adopting them.
IMHO, a good cross-platform solution would be to either use top level windows and palettes (dockable on Windows) on every platform, or have tabbed windows on Windows/Linux and top level windows on Mac. Again, the toolkit can abstract much of this. (wxWidgets I know is coming up with a more cross-platform friendly way of handling multiple document windows, but I admittedly haven't played with it myself.)
By the time you've special-cased all of these there's not all that much machine-independent code left:-(
Sure there is. Dialogs, menus, notebooks/tabs, windows, controls, sliders, process gauges, etc., etc., etc. Going with 3 different native toolkits means learning how to create and manipulate each of these controls 3 separate ways. Not to mention learning three event handling systems, three application frameworks, etc. In the end, people deal more with the GUI "building blocks" than the special cases. (But the special cases are what people remember, because they're a lot more interesting and challenging. ;-)
Also, most of the problems you outlined (in fact, all but the first and last, I'd argue) are at their core issues with developers not knowing how to target the Mac platform. The way to resolve that is to tell developers what they should and should not do if they wish to target the Mac platform. In other words, a "Mac development tips for Windows developers" type of guide. (Or actually, a "wxWidgets HIG" which explains how to create solid cross-platform interfaces.) The idea is that, by using this guide, programmers can avoid the most serious pitfalls without even having access to all the platforms they develop for.
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...
Taking an approach that deals with three different toolkits, you have to be aware of many more issues and you have to be competent in programming against three toolkits that sometimes have very different levels of abstraction (i.e. some are more low-level than others) and very different programming philosophies. You'll have to keep all that straight, and learn how to do everything three different ways. That is pretty darn difficult, and costly. In fact, some developers use wxWidgets for Windows only apps simply because the wxWidgets framework is easier to deal with than using the Microsoft APIs. ;-)
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.
But you will save a LOT on the former. ;-) And, theoretically at least, the debugging and testing phases should also be cheaper because the developer will spend less time working out platform/toolkit-specific bugs and more time on app-specific bugs. The wxWidgets APIs will handle most of that for him/her.
For the packaging part, I guess I should have mentioned I'm writing a wxWidgets-style installer which will create NSIS/Inno/RPM/DEB/.app/.pkg/etc. installers based off a master installation file. So eventually, you will save on that too, but to be fair you wouldn't need to use wxWidgets as your toolkit to get that benefit. ;-)
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.
I think the main difference here is that you see said disadvantages as inherently built into all cross-platform toolkits, while I see those disadvantages as things that more or less can be addressed/removed, if makers of the toolkit wish to do so. By improving the software, and improving the documentation, I think we can make it so that you can create high-quality Mac apps with wxWidgets, that are native in every sense of the word. I'll agree that wxWidgets isn't totally "there yet" for Mac, but it's a *lot* better than it was even a year ago.
Well, in any case, I'm one of those people who thinks actions count more than words. I'm not the fastest guy out there, but when I set my sights on it, I do keep working at it. I'm nothing if not stubborn. So I'll continue along with the other wx devs to try to be able to show you how good a cross-platform toolkit actually can be. If we can make something that Mac users can grudgingly accept as capable of making good Mac interfaces, I'll feel we've accomplished our goal. :-)
Thanks,
Kevin
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
