Archive for February 2006
Friday, February 24, 2006
When I first started developing Mac software, I used OmniOutliner to keep track of feature requests, bugs, and notes about what I was working on at the moment. It was great for organizing little bits of information, but it wasn’t quite powerful enough.
I soon switched to a Mac build of CVSTrac. Being Web-based, this was more cumbersome to use, but it provided better search options, and the Web interface made it very flexible at displaying different windows and views of the information. Most importantly, it integrated with CVS. CVSTrac includes a great CVS browser, which I could have used by itself. But I also used it to track issues, because I wanted to be able to see which tickets corresponded to which check-ins. CVS assigns revision numbers per-file, but CVSTrac is able to group the revisions (and display the changes) by check-in. It has a nice timeline that interleaves check-ins and ticket changes. CVSTrac isn’t good for storing rapidly changing notes (which I create and edit while coding a particular feature or fix), so I used BBEdit for that.
Naturally, when I switched from CVS to Subversion, I switched from CVSTrac to Trac. I like Trac even better than CVSTrac, except that it’s kind of a pain to install. When I got my iMac Core Duo I started thinking about building a universal binary version of Trac and realized that would be even more of a pain.
(I want to be able to sync it between my iMac and PowerBook and run it at full speed on both machines—Web applications are slow enough without Rosetta. Actually, to run in Rosetta isn’t quite trivial, either; it would probably involve making a stripped python binary and changing some shebang lines.)
None of this would have been difficult, but it was enough work that it got me to think about whether there might be an easier way. At this point, I realized that I don’t need Trac for issue-tracking. Subversion has built-in support for revision numbers, so I can use a separate tool for issue tracking and simply enter the revision numbers in the appropriate places. Since I’m a solo developer, I don’t need a Web-based solution; I can use a real Mac application that saves regular files to disk. When I need to browse Subversion, I can use BBEdit, or fall back on Trac.
The tool I chose for issue tracking is OmniOutliner 3.5 Pro. My use of versions 1.x and 2.x was very basic, and so I kind of ignored the later releases because I didn’t think I’d be using their extra features, anyway. Now I see that 3.5 Pro is a huge improvement, to the point where I can use it for all kinds of things that 2.x wouldn’t have been able to handle. I’ve always liked outliners,
but I didn’t use them as much as I would have liked to because there weren’t any that did enough of what I needed. OmniOutliner 3.5 Pro seems to be the release that crosses that threshold.
The most important new features for me are sections (for navigation and scoped searches), styles (very useful, even just for on-screen editing), and attachments (to associate troublesome input files, code, and documentation with a row). I also appreciate that it’s much less buggy than 2.x was.
In addition to the stuff from Trac, I’ve moved some lists and notes that used to be in BBEdit into my Issues outline. Obviously, the biggest improvement is that it’s much easier to make small changes and to re-arrange items compared with using a Web-based interface. It’s like taking off a straightjacket. And I prefer a flexible hierarchy, combined with columns and styles, to Trac’s Component-Milestone-Priority-Severity filing system. But, more than that, OmniOutliner has achieved a level of polish such that it no longer gets in my way. This makes all the difference because OmniOutliner is now (along with BBEdit and Mailsmith) one of the applications that I think in. Anything that isn’t fluid is is more than an annoyance; it’s an impediment to thought.
However, I’ve also noticed two somewhat unexpected benefits compared with Trac. First, it makes much better use of screen space. I can see more in less space, especially when I use the Hoist feature. Second, it’s nice to have my outlines in a separate window layer from my BBEdit and Safari windows. True, Mac OS X windows aren’t rigidly layered by application the way they were in OS 9, but the tendency is still there. I like to be able to bring all my code windows to the front by clicking on BBEdit’s Dock icon, but I also like that this doesn’t bring my notes to the front, since they’re in OmniOutliner.
On the whole, the switch has been great, but there are a few areas I’m not satisfied with yet. First, I’d like to be able to open more than one window for each outline, so I could view different parts of it at once, or view details along with the main structure. This would be great in combination with hoisting. Second, OmniOutliner can be very slow when pasting in a lot of rows. Lastly, I haven’t quite figured out when to use child rows and when to use notes. With 2.x, this was obvious, but 3.5 Pro offers so many options—for formatting rows, temporarily collapsing row text, showing notes inline, and spanning them—that the distinction between rows and notes is blurry in my mind. For now, I use rows for everything.
Amit Singh (via Ken Edwards):
We now have Windows XP running on the Intel-based Macintosh — as a guest operating system under the Linux version of VMware. This is quite exciting and promising, especially since the performance of Windows XP seems quite amazing (based on our limited test run so far) — mind you, the kernel and the environment we are using are experimental and unoptimized, so it would not be unreasonable to expect even better performance.
To anybody who has used Windows XP under Virtual PC on the PowerPC version of Mac OS X: you will simply be blown away by how fast Windows XP runs under VMware on the new hardware.
Tuesday, February 14, 2006
Daniel Jalkut:
In the years since Mac OS X was first released, the basic “Quartz Window” has been increasingly used as the workhorse element in providing the glitzy UI features we take for granted. An average user looking at their desktop, with all Finder windows closed, would answer “none” to the question “how many windows are open?” But there are dozens if not hundreds of windows being displayed in part or full on a typical Mac user’s screen. They just don’t look like windows.…Broken windows occur when the system or a developer attempts to use a (user level) window to achieve a tricky end, without taping up all the loose ends.
One of those loose ends, which he describes, is the way Cocoa handles AppleScript access to windows.
Monday, February 13, 2006
Slava Karpenko advises developers not to offer them, and:
If you’re a user, sure, free upgrades for life sound great, but come to think of it—if a certain software title promises you that, expect the maker to exit the business or abandon that particular product sooner or later. They simply can’t support themselves and justify adding features when they know they will never get that additional cash in. So why bother making a 2.0 if you know all the hundreds of hours of your hard work are going to be not paid off? I know too many examples of that to count.
It’s true. I don’t like it when I’m asked to upgrade every few months or even once a year, but on the other hand if a product claims to include free upgrades forever I also tend to stay away. My own products have gotten lots of free updates since they were introduced. The 2.0 upgrades were free as a thank-you to the early adopters and because it hadn’t been that long since 1.0. The 3.0 versions will be paid upgrades, however I plan to be very generous about giving free upgrades to people who bought 2.x recently. The month or two that developers often go back isn’t enough, in my opinion. But the 15 or so months that the Path Finder folks used is too much, except in that case—they were keeping a specific promise. I think the right number is somewhere between six months and a year.
Path Finder
Thursday, February 9, 2006
The Cocoa rewrite of Script Debugger (one of my favorite applications) looks like a great update. At last, it supports long filenames. The interface is much improved, with fewer windows and palettes to keep under control. The dictionary viewer has been redesigned, and you can type Command-D to open the dictionary for the current tell block. There are numerous improvements I haven’t mentioned.
Unfortunately, it’s not yet Universal, and some features from 3.x were removed. Script Debugger itself is no longer scriptable, and so it doesn’t work with BBAutoComplete. The Edit With BBEdit command is gone. The editor view doesn’t seem to be based on NSTextView, and so Cocoa’s auto-completion doesn’t work, either.
AppleScript BBAutoComplete Script Debugger
Saturday, February 4, 2006
Pierre Igot:
I am simply flabbergasted that Apple has not even fixed the font smoothing bug. After a whole year, they still haven’t read the bug reports and noticed that Pages fails to use the font smoothing style selected in “Appearance” in System Preferences? Unbelievable. The only rational explanation is that they somehow “forgot” to take the system’s font smoothing style into account when they first created the text rendering engine used in Pages, and now they would have to redo that text rendering engine itself in order to make it compatible, and they have just decided that it’s not worth the trouble. That doesn’t make it any less scandalous. First of all, how could they neglect to use the system’s font smoothing style in the first place? And now, how can they justify forcing users to cope with text in the wrong font smoothing style, especially given than most recent Macintosh computers use flat panel displays?
I’m not an expert on Quartz, but I don’t believe Pierre’s theory. As I learned several months ago, there are quite a few applications that don’t use the chosen font smoothing style. The pattern I see is that applications like Pages and OmniGraffle draw
multiple layers with possibly overlapping elements. A logical way to implement this is to draw the elements separately into off-screen buffers and then composite them together. As far as I know, you can tell Quartz to use font smoothing or not to use it (CGContextSetShouldSmoothFonts), but you can’t tell it which style to use. Quartz automatically chooses the “right” font smoothing style, and the right style for anything but on-screen drawing is to use the CRT style.
Thus, unless your application draws directly into a view, it will sometimes use the “wrong” style. An interesting case is OmniGraffle, which normally uses the CRT style. However, while you’re editing text it uses the LCD style, presumably because the field editor is drawing directly into the view. (If you’ve written one of these drawing applications, please feel free to correct me.)
With the current Quartz API, it doesn’t look to me like this would be easy to fix. It’s not that the text rendering engine would have to change, but that the entire layout and compositing engine would. My guess is that this would reduce performance and needlessly complicate lots of code that’s unrelated to text rendering. It would seem that the best fix would be for Apple to allow the application to choose the font smoothing style, though perhaps it had good reasons for not allowing this in the first place.
Font Smoothing iWork Mac Mac App OmniGraffle Pages.app Quartz
Luis de la Rosa has compiled a list of how long it takes to compile Subversion on various Macs. My iMac Core Duo (2 GHz, 2 GB) took 1:57. My dual-progressor G5 (2 GHz, 2.5 GB) took 4:31 with no applications running, after it had been on for a day. When I restarted and timed it again it was, as expected, much faster: 2:46.
Wednesday, February 1, 2006
