As I occasionally let on, my day job is the care and feeding of an ancient, semi-well known, Carbon application (and worse its Win32 doppleganger, and worse still its Win32 doppleganger's OLE interface). One "perk" is the occasional confrontation with the living dead. The dead in question is how we print. We print using a very old and elaborate system of QuickDraw calls spiked with embedded Postscript. This creates very nice output. On Postscript printers. From PowerPC Macs.
For Intel Macs, not so good. Why? Because there is no embedded Postscript in Quickdraw printing support for Intel Macs. It didn't make the cut of creaky technologies Apple bothered porting over during the Intel transition. So, yes, text and polygons look OK, if imprecisely positioned, and that's most of our output; but anything splined based is bad as there are no splines in QuickDraw only very big polygons.
So, users of ancient Carbon applications: check out the printing on your shiny new Intel box.
Showing posts with label OS X. Show all posts
Showing posts with label OS X. Show all posts
Thursday, October 02, 2008
Wednesday, December 19, 2007
The Chaotic Nature Of Window's Menus
As part of my day job, I've recently become familiar with the creation, display, and destruction of menus on the Windows platform. In writing this entry, I hope not only to point out the esthetic and technical disaster which is the Win32 menu framework, but offer a caution against getting in the same sort of problems on the Mac.
From the users point of view, menus on Windows are a chaotic mix of styles. While, we Mac users are used to the menus of each application looking the same on any given OS version, Windows users are treated with menus of wildly varying style, depending on the artistic sensibility of the individual programmer. Here are just a few of the menus found on my wife's fairly vanilla Windows Vista install:
Note the random selection of:
Contrast this with a selection of applications on Mac OS X Leopard:
Although even Apple can't protect us from the attack of the ugly cross-platform icons:
Why the disparity? Because when programming to the Win32 API, Microsoft requires all but the simplest menus to be drawn by application code responding to simple window events: WM_DrawItem, WM_MeasureItem. The system doesn't make it obvious where to draw your text, how to highlight selections, what the margins are, etc. The only thing the system will do for you is erase the background. If all you want to do is draw an icon: perhaps the favicon for a website, you have to manually draw the whole menu item, and if you want any hope of having that menu item look like all the other menu items in that menu, then you have to draw all the items in that menu, and if you do that, you will want to draw all the menu items in all the menus. If you code using the MFC framework, you will end up using some 3rd party menu class, written by somebody in the same boat as you, having to emulate and approximate whatever style is used by their favorite Microsoft app on any particular OS. Future changes in appearance will not magically appear with a new OS, but require each application to be reprogrammed, or at least to have a dynamic library updated.
Again, the major reason Windows programmers draw their own menus is to add an icon to a handful of menu items—which is usually the idea of some marketing guy anyway. If Microsoft had only added the ability to provide a graphic, few people would have bothered to draw their own. Life is short. If they had done so, they could have added all sorts of cool wizbangery to Vista, and we Mac users would be reduced to complaining how they stole translucent menus from Apple.
And while it may seem like a minor thing, Microsoft does not provide separate routines to specify the text of a menu and its key equivalent accelerator. Even if you aren't drawing a menu yourself, you have to provide a string like "&Redo\tShift+Ctrl+Z".
Hopefully, .NET programmers have an easier time.
The net effect of all this is that Microsoft cannot:
* Resolution independence is the idea that in our future of ultra-high resolution monitors, a menubar for instance won't be 25 pixels tall, but will be 25 points (25/72nds of an inch) with very high quality text.
But.
While all this Microsoft bashing is fun, this is a morality tale of a sort. Apple in its wisdom has given Cocoa developers much more control over how menus are drawn in Leopard. You can in fact, draw anything you please in a menu now. Don't do it. It was bad enough when you could clutter up your menus with blocky little useless icons, now the user can innocently click on a menu and be confronted with the Gates of Hell. Don't do it. Resist the temptation. Put the NSView down. If you are porting a Windows app, do not let the pointy haired boss force you into porting the ugly menus. Tell him it can't be done. Tell him you would lose Tiger compatibility. Tell him anything, but don't mess with Mac menus.
[Entry updated to point out more things wrong with the Windows menus and to add detail.]
From the users point of view, menus on Windows are a chaotic mix of styles. While, we Mac users are used to the menus of each application looking the same on any given OS version, Windows users are treated with menus of wildly varying style, depending on the artistic sensibility of the individual programmer. Here are just a few of the menus found on my wife's fairly vanilla Windows Vista install:
Note the random selection of:
- Highlight colors
- Separator graphics
- Highlight region shapes
- Margins
- Margin separators
- Root menu item shapes
- A ball icon where another application would use a check mark
- A "Ctrl-P instead of a "Ctrl+P"
- Minimum spacings between the title and the accelerator
- Sizing of the submenu triangle
- Drawing modes for greying out icons
- Degrees of fade for greyed out text
- Alignments of the accelerator text
Contrast this with a selection of applications on Mac OS X Leopard:
Although even Apple can't protect us from the attack of the ugly cross-platform icons:
Why the disparity? Because when programming to the Win32 API, Microsoft requires all but the simplest menus to be drawn by application code responding to simple window events: WM_DrawItem, WM_MeasureItem. The system doesn't make it obvious where to draw your text, how to highlight selections, what the margins are, etc. The only thing the system will do for you is erase the background. If all you want to do is draw an icon: perhaps the favicon for a website, you have to manually draw the whole menu item, and if you want any hope of having that menu item look like all the other menu items in that menu, then you have to draw all the items in that menu, and if you do that, you will want to draw all the menu items in all the menus. If you code using the MFC framework, you will end up using some 3rd party menu class, written by somebody in the same boat as you, having to emulate and approximate whatever style is used by their favorite Microsoft app on any particular OS. Future changes in appearance will not magically appear with a new OS, but require each application to be reprogrammed, or at least to have a dynamic library updated.
Again, the major reason Windows programmers draw their own menus is to add an icon to a handful of menu items—which is usually the idea of some marketing guy anyway. If Microsoft had only added the ability to provide a graphic, few people would have bothered to draw their own. Life is short. If they had done so, they could have added all sorts of cool wizbangery to Vista, and we Mac users would be reduced to complaining how they stole translucent menus from Apple.
And while it may seem like a minor thing, Microsoft does not provide separate routines to specify the text of a menu and its key equivalent accelerator. Even if you aren't drawing a menu yourself, you have to provide a string like "&Redo\tShift+Ctrl+Z".
Hopefully, .NET programmers have an easier time.
The net effect of all this is that Microsoft cannot:
- Upgrade the operating system and come up with a cool new appearance in which all the 3rd party applications (or even old Microsoft applications) magically share how their menus appear. Click on a menu and it's 1986 all over again.
- Have any kind of unified appearance.
- Replace those awful looking, English-centric, and space hogging accelerators with elegant Apple style meta key glyphs.
- Seamlessly move to *resolution independent GUIs. Apple's having trouble getting 3rd party applications to be resolution independent, but the fact that the OS draws the menus at least eliminates that as a problem.
* Resolution independence is the idea that in our future of ultra-high resolution monitors, a menubar for instance won't be 25 pixels tall, but will be 25 points (25/72nds of an inch) with very high quality text.
But.
While all this Microsoft bashing is fun, this is a morality tale of a sort. Apple in its wisdom has given Cocoa developers much more control over how menus are drawn in Leopard. You can in fact, draw anything you please in a menu now. Don't do it. It was bad enough when you could clutter up your menus with blocky little useless icons, now the user can innocently click on a menu and be confronted with the Gates of Hell. Don't do it. Resist the temptation. Put the NSView down. If you are porting a Windows app, do not let the pointy haired boss force you into porting the ugly menus. Tell him it can't be done. Tell him you would lose Tiger compatibility. Tell him anything, but don't mess with Mac menus.
"Just because we can do a thing does not mean we must do that thing." The Federation President in Star Trek: The Undiscovered Country
[Entry updated to point out more things wrong with the Windows menus and to add detail.]
Thursday, November 22, 2007
There Must Be a Cocoa iTunes Coming + Vista 64-bit iTunes?
[Update: Apple released iTunes 8, and whatever it is, it is not pure Cocoa]
[Update: Apple did release a version of iTunes for 64 Bit Vista. I don't know how it matches up with the below speculation. ]
This is entirely speculation on my part. If I had insider information, I would not betray it. This is just my uninformed opinion.
Fact 1: iTunes as we know it is a Carbon application on the Mac. It after all is the direct descendent of SoundJam, a short-lived MP3 player for Classic Mac OS. Open up its package in the Finder and see things like a .rsrc file.
Fact 2: iTunes makes heavy use of QuickTime and the Mac Toolbox emulation layer which QuickTime for Windows contains. This is what allowed the same codebase to be deployed on both OS X and Windows relatively quickly. (OK, this may not be a fact, not having access to the iTunes code, but it seems darn likely.)
Fact 3: There is no 64-bit C API to QuickTime on the Mac. There is only a 64-bit Cocoa interface.
Fact 4: Pretty much all of that Mac Toolbox being emulated on Windows is no longer available under 64-bit compiles on the Mac.
Fact 5: All new Macs are 64-bit. Apple is in a good position to start promoting themselves as The 64-bit Company, as their path to 64 purity seems easier than Microsoft's, but it will take getting all their apps there first, and convincing their major developers to follow. I assume it was easy getting their Cocoa applications there, but any residual Carbon applications would be a nightmare.
Extrapolation 1: Even Apple will not be able to make iTunes a 64-bit application without a major rewrite. After you remove QuickTime, all the old Classic Mac APIs which are not in the 64-bit frameworks, etc., there is little left. Maybe much of the task specific onscreen drawing on the Mac is now done with Quartz calls, and the networking calls are probably being done with CFNetwork calls on the Mac, and maybe they are using WebKit to do the store, and that can all be salvaged, and hopefully the code is factored such that system calls are not sprinkled all over the place, but they are going to have to bite the bullet and just write a from scratch Cocoa application and call it iTunes 8.
Extrapolation 2: If Apple is not going to extend the life of Classic Mac APIs and QuickTime C APIs for 64-bit Mac applications, what are the odds of them doing so for the emulation layer on 64-bit Vista. Pretty low. There is no obvious quick way to get iTunes as we know it on Windows to run as a 64-bit process. I guess they could if they really wanted to, but it seems a pretty hacky solution and would basically obligate them to maintain an entire OS's SDK just to run iTunes and QuickTime.
Extrapolation 3: I assume Apple cares about the future of QuickTime and iTunes on 64-bit Windows. This is not a big market now, but will only get bigger, and Windows user are not going to accept running multimedia software in 32-bit emulation mode in perpetuity. They can do two things. They can create a new framework which can play and edit QuickTime content, perhaps a set of .NET classes, and write a separate version of iTunes which makes use of these classes. Or, they can bring Cocoa to 64-bit Windows, and run the same source based iTunes as the Mac. I suspect Apple doesn't want to do either, but iPod sales are important to them. They wouldn't want those early adopter 64-bit users running to Zune.
A little Googling on "64-bit iTunes" came up with this revealing alert text in the current Windows iTunes "This iPod cannot be used because the required software is not installed. Run the itens installer and remove itunes, then install the 64-bit version of iTunes." That makes me wonder if all this is going to fall out sooner rather than later. Or maybe it's an aberration.
Anyway, that's my uninformed opinion, and we'll see if it has any relationship to reality.
[Update: See this article about how Adobe is not releasing a 64-bit version of Photoshop until they can do the major re-writing required to remove their Carbon code.]
[Update: Apple did release a version of iTunes for 64 Bit Vista. I don't know how it matches up with the below speculation. ]
This is entirely speculation on my part. If I had insider information, I would not betray it. This is just my uninformed opinion.
Fact 1: iTunes as we know it is a Carbon application on the Mac. It after all is the direct descendent of SoundJam, a short-lived MP3 player for Classic Mac OS. Open up its package in the Finder and see things like a .rsrc file.
Fact 2: iTunes makes heavy use of QuickTime and the Mac Toolbox emulation layer which QuickTime for Windows contains. This is what allowed the same codebase to be deployed on both OS X and Windows relatively quickly. (OK, this may not be a fact, not having access to the iTunes code, but it seems darn likely.)
Fact 3: There is no 64-bit C API to QuickTime on the Mac. There is only a 64-bit Cocoa interface.
Fact 4: Pretty much all of that Mac Toolbox being emulated on Windows is no longer available under 64-bit compiles on the Mac.
Fact 5: All new Macs are 64-bit. Apple is in a good position to start promoting themselves as The 64-bit Company, as their path to 64 purity seems easier than Microsoft's, but it will take getting all their apps there first, and convincing their major developers to follow. I assume it was easy getting their Cocoa applications there, but any residual Carbon applications would be a nightmare.
Extrapolation 1: Even Apple will not be able to make iTunes a 64-bit application without a major rewrite. After you remove QuickTime, all the old Classic Mac APIs which are not in the 64-bit frameworks, etc., there is little left. Maybe much of the task specific onscreen drawing on the Mac is now done with Quartz calls, and the networking calls are probably being done with CFNetwork calls on the Mac, and maybe they are using WebKit to do the store, and that can all be salvaged, and hopefully the code is factored such that system calls are not sprinkled all over the place, but they are going to have to bite the bullet and just write a from scratch Cocoa application and call it iTunes 8.
Extrapolation 2: If Apple is not going to extend the life of Classic Mac APIs and QuickTime C APIs for 64-bit Mac applications, what are the odds of them doing so for the emulation layer on 64-bit Vista. Pretty low. There is no obvious quick way to get iTunes as we know it on Windows to run as a 64-bit process. I guess they could if they really wanted to, but it seems a pretty hacky solution and would basically obligate them to maintain an entire OS's SDK just to run iTunes and QuickTime.
Extrapolation 3: I assume Apple cares about the future of QuickTime and iTunes on 64-bit Windows. This is not a big market now, but will only get bigger, and Windows user are not going to accept running multimedia software in 32-bit emulation mode in perpetuity. They can do two things. They can create a new framework which can play and edit QuickTime content, perhaps a set of .NET classes, and write a separate version of iTunes which makes use of these classes. Or, they can bring Cocoa to 64-bit Windows, and run the same source based iTunes as the Mac. I suspect Apple doesn't want to do either, but iPod sales are important to them. They wouldn't want those early adopter 64-bit users running to Zune.
A little Googling on "64-bit iTunes" came up with this revealing alert text in the current Windows iTunes "This iPod cannot be used because the required software is not installed. Run the itens installer and remove itunes, then install the 64-bit version of iTunes." That makes me wonder if all this is going to fall out sooner rather than later. Or maybe it's an aberration.
Anyway, that's my uninformed opinion, and we'll see if it has any relationship to reality.
[Update: See this article about how Adobe is not releasing a 64-bit version of Photoshop until they can do the major re-writing required to remove their Carbon code.]
Wednesday, November 21, 2007
The Future or Lack of It for Carbon
If you are tasked with maintaining a large, old—is there any other kind—Carbon application, here's an illuminating experiment. In XCode 3.0, under Build architecture, turn on 64 bit compilation for Intel. Now try to compile.
In my case, I see errors and lots of them:
So, we have a litany straight out of Inside Macintosh Vol. 1-3: all of QuickDraw, much of the File Manager, the Control Manager, the Dialog Manager, the Window Manager, the Menu Manager, the Font Manager all gone, but surprisingly not the Resource Manager. Anything that uses Pascal strings or FSSpecs. Few of the API's which came from the Classic Mac OS survive a 64 bit compile.
I don't know in the short term, what the carrot is for getting independent developers to make 64-bit compiles. Unless you are doing something that really needs 6 GB of real RAM—very few applications—there seems to be little performance advantage for 64-bit. And, it's hard taking a Carbon application, ripping out the APIs behind its entire GUI, and putting it back together again. Lots of redesign and drudgery for little immediate payoff. In the long term, Apple will presumably stop supporting 32-bit applications, but that is in the very long term.
Plus, there are little bits of functionality in the Carbon APIs which are hard to replicate in the more modern APIs. One example is embedding one's private metadata in the PICT clipboard flavor. I'd very much like to know how to do that with the PDF API. Another example is the XOR drawing mode for doing tracking, stupid and old fashioned, yes, hard to replace, yes.
There's an Ars Technica article which goes into this in more detail.
In my case, I see errors and lots of them:
error: '::FlushVol' has not been declared
error: 'HideCursor' was not declared in this scope
error: 'ShowCursor' was not declared in this scope
error: 'LMGetFractEnable' was not declared in this scope
error: 'GetOutlinePreferred' was not declared in this scope
error: 'GetPreserveGlyph' was not declared in this scope
error: 'GetWindowEventTarget' was not declared in this scope
error: 'SetFractEnable' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'MoveWindow' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'OpenCPicture' was not declared in this scope
error: 'SetControlPopupMenuHandle' was not declared in this scope
error: '::SetControlMaximum' has not been declared
error: '::DrawThemeMenuItem' has not been declared
error: 'GetIntlResource' was not declared in this scope
error: 'CompareString' was not declared in this scope
error: '::SetMenuWidth' has not been declared
error: 'IsWindowVisible' was not declared in this scope
error: '::GetPicture' has not been declared
error: '::DrawPicture' has not been declared
error: '::EraseRect' has not been declared
error: '::FindDialogItem' has not been declared
.... lots more errors ...
So, we have a litany straight out of Inside Macintosh Vol. 1-3: all of QuickDraw, much of the File Manager, the Control Manager, the Dialog Manager, the Window Manager, the Menu Manager, the Font Manager all gone, but surprisingly not the Resource Manager. Anything that uses Pascal strings or FSSpecs. Few of the API's which came from the Classic Mac OS survive a 64 bit compile.
I don't know in the short term, what the carrot is for getting independent developers to make 64-bit compiles. Unless you are doing something that really needs 6 GB of real RAM—very few applications—there seems to be little performance advantage for 64-bit. And, it's hard taking a Carbon application, ripping out the APIs behind its entire GUI, and putting it back together again. Lots of redesign and drudgery for little immediate payoff. In the long term, Apple will presumably stop supporting 32-bit applications, but that is in the very long term.
Plus, there are little bits of functionality in the Carbon APIs which are hard to replicate in the more modern APIs. One example is embedding one's private metadata in the PICT clipboard flavor. I'd very much like to know how to do that with the PDF API. Another example is the XOR drawing mode for doing tracking, stupid and old fashioned, yes, hard to replace, yes.
There's an Ars Technica article which goes into this in more detail.
Wednesday, June 20, 2007
Which Mac OS X should I Support?
A critical decision any developer of Mac OS X software has to make is where to draw the line between users we can be troubled to support, and which users we can tell to come back when they have a newer operating system. It comes down to number of users, and effort to support. First, the numbers. According to Steve Job's recent WWDC keynote there are 15 million Tiger users, 5 million Panther users and 2 million users of older operating systems.
This is for the overall Mac community; the market segment you intend to develop for may be different. Maybe you are targeting the elementary school market where 5 year purchasing cycles create huge pockets of happy 10.2.8 users (I guess). Or maybe you are targeting the top end photo editing business where the release of universal binary Photoshop has released a maelstrom of hardware and software purchasing the like not seen since the world was young (another guess). Temper these absolute numbers knowing somebody who hasn't shelled out money in 6 years to buy a new OS is unlikely to buy third party apps. Regardless, these are the numbers we have and what we'll use.
Apple itself is always happy to tell its developers to forget about users of older releases--not in so many words. If these users find they cannot run some new application they will gradually feel the pressure to upgrade, and hopefully upgrade to new hardware, but even selling a $129 OS upgrade to some iBook G4 user is nearly pure profit to Apple. Also, Apple wants us to integrate new OS features: hard to do while still holding onto 10.2.8 support.
There are over a million people out there running 10.2.8 and some small number running 10.1, and some unlucky few running 10.0 who couldn't be bothered to get the free 10.1 upgrade. Should developers support them? No.
Why?
Realistically, only a product with a near 100% installed base and a huge development team like Acrobat Reader would even think about supporting 10.2, and look even Adobe's minimum OS is 10.4.3.
OK, well what about 10.3? Those 5 million users are awfully tempting. Yes they are. And I'd still lean against supporting them with any project you are starting today. Why?
So my advice is to target 10.4, and be thankful you never had to support Windows ME. The horror, the horror.
This is for the overall Mac community; the market segment you intend to develop for may be different. Maybe you are targeting the elementary school market where 5 year purchasing cycles create huge pockets of happy 10.2.8 users (I guess). Or maybe you are targeting the top end photo editing business where the release of universal binary Photoshop has released a maelstrom of hardware and software purchasing the like not seen since the world was young (another guess). Temper these absolute numbers knowing somebody who hasn't shelled out money in 6 years to buy a new OS is unlikely to buy third party apps. Regardless, these are the numbers we have and what we'll use.
Apple itself is always happy to tell its developers to forget about users of older releases--not in so many words. If these users find they cannot run some new application they will gradually feel the pressure to upgrade, and hopefully upgrade to new hardware, but even selling a $129 OS upgrade to some iBook G4 user is nearly pure profit to Apple. Also, Apple wants us to integrate new OS features: hard to do while still holding onto 10.2.8 support.
There are over a million people out there running 10.2.8 and some small number running 10.1, and some unlucky few running 10.0 who couldn't be bothered to get the free 10.1 upgrade. Should developers support them? No.
Why?
- You want to use invasive technologies like Core Bindings which are 10.3 and above.
- You won't be able to debug and still use the latest developer tools.
- You are going to find that these people are 5% of your user base but manifest 50% of your bugs.
- Your graphics are going to look awful, trust me.
Realistically, only a product with a near 100% installed base and a huge development team like Acrobat Reader would even think about supporting 10.2, and look even Adobe's minimum OS is 10.4.3.
OK, well what about 10.3? Those 5 million users are awfully tempting. Yes they are. And I'd still lean against supporting them with any project you are starting today. Why?
- Debugging, while possible, is hard. Maybe you are the master of command line gdb or remote debugging, but I am not.
- By the time you get finished October will be here and those 10.3 users will be squished into a smaller slice by Leopard.
- There are many 10.4 specific technologies in Cocoa and Core Foundation that I'd like to use.
- A one or two person team only has so much time, and there are a lot of better places to put your effort.
So my advice is to target 10.4, and be thankful you never had to support Windows ME. The horror, the horror.
Monday, June 04, 2007
The Golden Age of OS X Independent Software
I've found myself buying a lot of software for my MacBook these days. It isn't because I'm swimming in money, because I most certainly am not. It's because I have software needs and wants, and my peers are out there satisfying them. Here is what I've paid my own money for in the last few months:
What do all this software have in common? Open their package contents in the Finder and you will see the unmistakable traces of Cocoa development. It's a lot easier today for one or two people to write an insanely polished application because we have Cocoa to handle the parts that every application does and we can concentrate on doing what makes our applications unique.
- Tables is a very satisfying spreadsheet which is nothing but a spreadsheet. It is very Mac-like, understated, stable and does what I expect of it. I chose it over Mesa, even though Mesa did charts because of its obvious emphasis on details. And now it does charts too, although they need a little work. I'd been using AppleWorks way past its expiration date.
- YummyFTP is exactly what I was looking for in an FTP client. Believe me, I tried many of its competitors before settling on this classy little Cocoa gem. I needed a client which could deal with an incredibly unstable Chinese FTP site, and this was up to the job.
- DVDPedia was recommended on the HT Guys podcast and I like it too. It has its share of interface issues, but a lot of craft has gone into it.
- Remote Buddy I've mentioned before. I know from experience that input devices are cranky things, but Remote Buddy makes handling them seem effortless.
- Super Duper!'s free features are so good, I haven't even paid for the premium features, but I probably will. After getting the heads up on this backup software from The Maccast I used it to transfer the contents of my hard drive before upgrading to a 200GB internal. Took a long while, but it was obviously very careful about protecting my data.
What do all this software have in common? Open their package contents in the Finder and you will see the unmistakable traces of Cocoa development. It's a lot easier today for one or two people to write an insanely polished application because we have Cocoa to handle the parts that every application does and we can concentrate on doing what makes our applications unique.
Sunday, April 29, 2007
Porting Model Railroading Software to OS X From Windows
Last week, TrainPlayer International released a Mac OS X version of Train Player, their application for designing model railroads. I had something to do with this. I setup the general structure of the application at the start of the porting project, implemented a number of features, and worked into the debugging stage. But my real job has been nothing but debugging for the last two months, and I have nothing left to give to side projects, so they've had to get along without me.
This blog entry is the first of two on the project. This will cover GUI differences between a Windows application and a Mac OS X application, in terms of user expectations. The second will be on designing an application under the hood to share code between a Cocoa application and an old MFC application.
When I worked in Illinois, we called this "Marketing Mode." Compare this with the left
and the right side of Apple's Pages word processor.
Apple Pittsburgh spent untold hours categorizing the actions required to lay out text, and distilled them into six icons. I can imagine the pressure they felt to add a special button here or there for someone's pet function. "What about a spell check button?" But it is important that toolbar icons be few and large in order that mouse acquisition times be short, requiring thoughtful selection of buttons. Notice there is plenty of room under the large icons for actual descriptive words; sometimes a word is worth a thousand pictures.
The second thing I noted was how often the user was required to open a modal dialog box, sometimes two, or even three nested modal dialogs to configure some user interface element. For example, to change the labels for a series of railway cars you would select a car, choose "Properties..." from the "Train" menu, to bring up this modal dialog:
which you would modify, hit "OK" and repeat for every car in the series. Modal dialogs are great for programmers; work flow is linear and controlled. If the user hits "Cancel" you just don't change your data structures, while if they hit "OK" nobody expects you to allow them to undo it; you've already given them a chance to back out. It's just so easy. But, Mac users these days are used to more.
The more they expect is a modeless, floating inspector window.
This allows the user to select, change and rapidly select and change again, all without losing focus on the document. It should allow for undoing changes (although apparently that functionality hasn't been added yet to Train Player, but should). The user should feel more comfortable and able to work in a more free flowing manner.
The Windows version used GDI graphics for its rendering needs, resulting in pixelated track paths like this:
I felt OS X's Quartz graphics environment would create much cleaner lines if we treated tracks as continuous paths instead of discrete segments and the Windows programmer was willing to make the changes needed to get nice anti-aliased and beautifully joined paths like these:
Similar effects could be achieved under Windows with GDI+, but I felt the typical Mac user would immediately see what was missing and demand higher quality. Quartz also allows any object to cast a shadow, making this effect:
extremely easy to produce. Simple as it is, this translucent shadow makes the cars pop out and resulting in a more realistic look.
Along the same vein, Windows users see this clock:
while Mac users will see this clock with a composited reflective crystal and hands throwing shadows:
The Windows version had a modal dialog to choose individual cars from collections. It had two modes: an icon view and a table view, with each collection selectable via a tab.
I felt there was no need for two modes as the Mac table class was capable of displaying the larger image; and I am leery of using tabs to represent categories, especially when the user could install or create their own. Therefore, I replaced the tabs with a single column table as you might see in an iLife application, and I merged the two modes into a single table grid.
In other areas, I left it up to the experts at TrainPlayer, they know model railroading, whereas I only know generic applications. So when they say this is how you build up a set of tracks, this is how you build a set of tracks:
And this is how you run a simulation on a completed railroad:
I wish YouTube didn't add an ugly filter to its videos. You have to see how pretty it is.
In other places, I'm not thrilled. After I left the project, too many buttons crept into the GUI, and text fields really should support undo. Today's standards are high, it's hard to keep up, especially while reusing large chunks of C++ code, and bitmap images from a Windows application. The good thing is there is always version 1.0.1.
Porting is a balancing act. You've got to know what code and what GUI elements can be reused, and which must be re-implemented in order to avoid the dreaded "Looks like a Windows port" review. I think we've avoided that, and that's an accomplishment in itself.
This blog entry is the first of two on the project. This will cover GUI differences between a Windows application and a Mac OS X application, in terms of user expectations. The second will be on designing an application under the hood to share code between a Cocoa application and an old MFC application.
What Mac Users Want
The first thing I noticed about the interface was the surfeit of toolbars. With buttons for nearly every action.When I worked in Illinois, we called this "Marketing Mode." Compare this with the left
and the right side of Apple's Pages word processor.
Apple Pittsburgh spent untold hours categorizing the actions required to lay out text, and distilled them into six icons. I can imagine the pressure they felt to add a special button here or there for someone's pet function. "What about a spell check button?" But it is important that toolbar icons be few and large in order that mouse acquisition times be short, requiring thoughtful selection of buttons. Notice there is plenty of room under the large icons for actual descriptive words; sometimes a word is worth a thousand pictures.
The second thing I noted was how often the user was required to open a modal dialog box, sometimes two, or even three nested modal dialogs to configure some user interface element. For example, to change the labels for a series of railway cars you would select a car, choose "Properties..." from the "Train" menu, to bring up this modal dialog:
which you would modify, hit "OK" and repeat for every car in the series. Modal dialogs are great for programmers; work flow is linear and controlled. If the user hits "Cancel" you just don't change your data structures, while if they hit "OK" nobody expects you to allow them to undo it; you've already given them a chance to back out. It's just so easy. But, Mac users these days are used to more.
The more they expect is a modeless, floating inspector window.
This allows the user to select, change and rapidly select and change again, all without losing focus on the document. It should allow for undoing changes (although apparently that functionality hasn't been added yet to Train Player, but should). The user should feel more comfortable and able to work in a more free flowing manner.
The Windows version used GDI graphics for its rendering needs, resulting in pixelated track paths like this:
I felt OS X's Quartz graphics environment would create much cleaner lines if we treated tracks as continuous paths instead of discrete segments and the Windows programmer was willing to make the changes needed to get nice anti-aliased and beautifully joined paths like these:
Similar effects could be achieved under Windows with GDI+, but I felt the typical Mac user would immediately see what was missing and demand higher quality. Quartz also allows any object to cast a shadow, making this effect:
extremely easy to produce. Simple as it is, this translucent shadow makes the cars pop out and resulting in a more realistic look.Along the same vein, Windows users see this clock:
while Mac users will see this clock with a composited reflective crystal and hands throwing shadows:
The Windows version had a modal dialog to choose individual cars from collections. It had two modes: an icon view and a table view, with each collection selectable via a tab.
I felt there was no need for two modes as the Mac table class was capable of displaying the larger image; and I am leery of using tabs to represent categories, especially when the user could install or create their own. Therefore, I replaced the tabs with a single column table as you might see in an iLife application, and I merged the two modes into a single table grid.
In other areas, I left it up to the experts at TrainPlayer, they know model railroading, whereas I only know generic applications. So when they say this is how you build up a set of tracks, this is how you build a set of tracks:
And this is how you run a simulation on a completed railroad:
I wish YouTube didn't add an ugly filter to its videos. You have to see how pretty it is.
What Was Achieved
In many ways, I'm proud of the result so far, and I expect the application to go through a rapid process of refinement now that it is available to a wider Mac user audience. Areas of the GUI where I varied it from the Windows original are definite improvements, some of which could be back ported to give the Windows user base a taste of Mac refinement.In other places, I'm not thrilled. After I left the project, too many buttons crept into the GUI, and text fields really should support undo. Today's standards are high, it's hard to keep up, especially while reusing large chunks of C++ code, and bitmap images from a Windows application. The good thing is there is always version 1.0.1.
Porting is a balancing act. You've got to know what code and what GUI elements can be reused, and which must be re-implemented in order to avoid the dreaded "Looks like a Windows port" review. I think we've avoided that, and that's an accomplishment in itself.
Subscribe to:
Posts (Atom)