Blog

A Superficial Review of TaskPaper (Cuz superficial is all my backlog allows)

It doesn’t matter how much we complain about time, we’re not being realistic or honest about our use of it. Everyone gets the same amount every day; that is, if we’re getting the whole day. But asking for more time to do things has to strike someone as having too many things to do, and being grown up enough to abandon or postpone those things for which there isn’t time.

There are plenty of Time Management systems out there. Gettings Things Done (GTD) is a recent one with a lot of buzz and adopters. There are plenty of GTD software packages for those who prefer computer-based systems to paper, including two versions for Mori: Jeff Fisher’s mGTD plugin and Jim Harrison’s MoriGTD scripted system.

Now, I’ve had the audiobook for GTD for years but I’ve never listened to it. (I did at least listen to Merlin Mann’s David Allen interviews when I was on the road.) And now that I’m developing (and using) Mori I’ve even installed the mGTD plugin, but that was more for testing purposes than actually knowing what GTD was about (or how to use it).

So when Jesse introduced his own GTD app, TaskPaper, as a simpler way to getting things done with “paper-like simplicity” I was of course concerned that it would cannibalize Mori sales. But TaskPaper only manages tasks, not notes like Mori does. So unless your notes are one-liners used only to manage your activities, you’ll still need to grab a copy of Mori. ;)

But the real reason not to be concerned is TaskPaper is an awesome app in its own right. Jesse prodded me a couple times to try it, and even provided me with a license. So the next time I needed to jot down a task reminder, instead of using Mori, I opened up TaskPaper and gave it a try.

Now I have to admit, being both a GTD noob and a programmer, TaskPaper’s interface threw me at first. Let’s face it, any device with less than five buttons on it leaves me scratching my head. But I do know how to use an outliner. So with that interface in mind I set out to discover just how it was earning such wonderful reviews.

But TP isn’t exactly an outliner. It just uses an outline-like interface, and I emphasize that point. You’ll be productive very quickly, but I also got my list complicated very quickly by adding sub-sub-headings to my project. (But you have to expect that from a GTD noob and a programmer.) The beauty is that by using a very simple text editor/outliner interface, TP doesn’t complicate the ability to change your organization of tasks and projects. Nor does it complicate your ability to add extra info about the task (its metadata). Avoiding special columns and a form interface, TP instead uses the following special text characters to signify meaning: “:” for projects, “-” for tasks, “[tab]” to nest tasks within other tasks (which are themselves nested within a project), any non-reserved character for notes, and “@” for the interesting context.

Contexts are GTD’s way of giving you a way of lumping similar activities together. They aren’t necessarily part of the same project, but just things which are done at the same place (e.g., @home, @mall), the same type of activity (@computer, @phone), and so on. TP refers to them as tags, and uses the normal GTD syntax (I guess) to refer to them.

TP’s interface is very sparse, which means less clutter and distractions. It’s nonetheless powerful, letting you filter to a specific project or context. The point is to spend more time doing your activities than actually organizing what they are. And TaskPaper handles that beautifully (and elegantly). I now understand what the Hog Bay Notebook users have been clamoring for!

I also have a better understanding of how GTD works, even more so after I sat through the mGTD screencast put up by Jeff, which in turn helped me make better use of TP and GTD.

There are definitely some features I’d like to see added, though:

The UI signifies task completion by changing the text style to strike-through, but the only way to mark the task as completed textually is by adding the context @done or the keyboard shortcut cmd-D. (You can also mark it completed by clicking on the open circle in the left margin or the menu item “Project > Mark as Done”, but that requires lifting your hands from the keyboard to use the mouse. I would prefer some other delimiter such as “x”, or a checkmark to signify completion, just for continuity.

I’d like to see true tags supported, perhaps using Chris Messina’s “#” tag delimiter.

So while there are some features I’d like to see added for more sophisticated capabilities, for GTD noobs like myself (still) and those who just want to work and not manage yet another system, TaskPaper should be the first stop to GTD (and priority) mastery!

In time, I might become profficient enough at GTD to be able to use mGTD or MoriGTD. But for now I just need to start the “filtering the inbasket thing” to help things along. That, and redefine my understanding of the word “superficial”.

Keep Tabs on Apokalypse Software Between Blog Postings With Twitter

Just a simple reminder, if you’ve got questions or suggestions regarding any Apokalypse products, I invite you to post them at the forums if they’ll be of benefit and/or interest to the communities which use the products.

Post feature requests and bug reports so I keep track of what needs to be done to keep these products relevant to the work you do. The issue tracking system even has a polling feature which allows you to vote on the most important issues for you.

For any communication which doesn’t apply to the community of users here, I invite you to contact me via private correspondence or iChat/AIM/IRC (huperniketes).

However, if you just want to know what’s currently transpiring, and what’s going on in-between the lengthy times between my irregular posts (I’ve got a huge backlog of unfinished posts, I do apologize), there’s another way to see what I’m up to. That technique is through the Twitter service.

Here’s a simple description of how Twitter is useful for me to keep you aware of what’s going on:

Ed Yourdon, whose Techniques of Program Structure and Design revolutionized my thinking and methods in developing software, has written a great example of why I use Twitter.

I invite you to follow my tweets, or those for Mori and Clockwork product info. I also invite you to sign up and send your own message to any of those accounts.

Web Site Issues Persist Still, Sometimes I’m to Blame, And “Hello, Mori 1.6.11!”

In spite of updating WordPress a couple months ago, a spammer has managed to hack his junk into the blog webpages. You can see it at the end the page source. It’s after the closing <html> tag, where browsers ignore it, but Google doesn’t. Looks like I’ll be dumping WP to handle the blog, and just let Drupal do it all, at least for the time being.

Another issue I frequently see in the logs is user activity which is denied. A few in particular are some pages which anonymous users were trying to access. Today, however, I noticed that a normal user tried to access one of those pages so I decided to investigate. That’s when I discovered he tried adding an entry to the Mori User Story page and the system refused him! How can we refuse a user’s desire to add his own story to the story page? So I fished around in the admin controls until I found a couple that might have prevented him from doing this generous thing for us. So, hopefully, he’ll once again feel the creative mood strike him to share his experiences with us. And if this oversight and ignorance on my part also hindered your desire to let the world know about the awesome work you’re doing in Mori, please give it another shot. The community is certainly happy to find more inspiration by what you’re doing. After releasing Mori 1.6.11, I know I certainly am!

That’s right. Mori 1.6.11 is finally out, and it’s got the major smackdown on a few nasties. First, problem #2608, freezing during Spotlight updating after emptying the trash. Fixed. Second, (hmm…no problem number. Oh, well.) user’s autosave interval not being respected by Mori. Fixed. And finally, a problem that I finally managed to isolate after the beta went out (which was this past Monday, July 7, 2008): intermittent crash when updating the live search database. That long-standing bug is now dead! (It’s so old I don’t even know where the bug report for it is.)

Anyway, enough progress has been made to Mori’s internal structure since the last update, that except for taking care of some long-neglected responsibilities this weekend, I’ve been working on the polish and features that will make it into 1.7! And I understand how frustrating it is not to know the details of what they are, but it would’ve given Mori’s competitors a chance to duplicate before it’s release. But I’m looking forward to its release so I can finally share what they are with you.

In the meantime, there’s still some issue with the mGTD plugin. So there might be a Mori 1.6.12 soon if we get the cause for it, and any other open bugs, nailed down in time.

Alfonso
P.S. Did you notice the View item in the toolbar? It allows you to select either table (immediate descendants) or outline mode for the entries view. I enabled that feature a few versions back. Give it a try, if you haven’t before. Also, try out the options for Layout in the View menu. The menu isn’t quite friendly enough yet, but it still gives you a lot of flexibility to work in your own style.

An Apology to Mori Customers – A New Mori Test Version Has Been Released

Back on August 27 of this year I stated the release of Mori 1.7 was imminentdue to the acquisition of an encryption utility which would provide the core of the reworked 1.7 feature list. That has now been four months. So once again I failed to deliver on the expectations I’ve set before you, and for that I apologize. I’ve just uploaded a new alpha test release (code-named Oneill) for your inspection, but before I list the specific features it contains I’ll explain why it’s taken so long, and why it’s only an alpha.

After I announced the changed development plan, one forum member wrote,

Most of the announced features [ie, “LinkBack, customized labels, font settings for source & entry views, better keyboard navigation, outlining improvements, self-downloading updates, and now encryption”] have either been tried to some degree in the failed versions, or are of marginal usefulness.

In my response I outlined the terrible decision I made to replace Mori’s view system with a more advanced, revamped one and how it was important to get new features (including encryption) into users’ hands now. I also disagreed with his characterization of the new feature set as trivial and tried before. However, I also offered to let you, Mori’s users, decide whether to include encryption in Mori and whether I should delay Mori 1.7 to get the new view system working or continue with the new course I had set to produce a new version quickly.

Although only 11 votes were cast on whether to delay, it was overwhelmingly pro-delay (even with my 1-star vote). So I decided to compromise and add some of the new view system and the originally promised features to Mori now, and continue making piecemeal changes afterwards.

Of course I should’ve mentioned my decision to you before, and for not explaining it to you I’m sorry. Once I made the decision, however, I just withdrew and set about getting the job done. (Although I hadn’t entirely withdrawn. As some have noted on the forum, I am far more communicative on Twitter as it limits content to 140 characters, which is very lightweight as a conversing medium. Unfortunately, I’m only aware of one Mori user who’s on Twitter and has made his presence known. Hi, Dale!)

So now that I’ve put out a new Oneill release, what does it actually contain? To quote from the release notes:

  • Multi-line rows is in operation. There is a speed issue (not having it), and a horrible display bug when adding characters to a multi-line row, but the text displays correctly once edits are done.
  • Users can now set different font styles for source and entry lists. Currently this setting affects all docs being displayed.
  • Notes can be zoomed in and out either via a pop-up menu on the footer, or through the new “View > Zoom” menu (and corresponding shortcut keys).
  • Users with MacBook Airs, and late 2008 model MacBooks and MacBook Pros can use gestures to zoom in and out as well.
  • Users with a 3Dconnexion SpaceNavigator can use it zoom in and out as well.
  • Various internal changes.

That’s right, you can adjust the font sizes for the source & entry lists, and zoom into your notes to make it easier for you to work with your info.

Multi-line entries for those extra-long topics or more complex outlines, as a start for the type of formatting you’ll be able to have in your Mori notebooks.

Support for gesturing and alternate input devices, starting with the multitouch trackpads on all the current Mac laptops and the 3Dconnexion Space Navigator.

So that’s where Mori’s development is now. I have more changes coming shortly, but I have a long drive ahead of me: Silicon Valley and Macworld 2009.

An Urgent Mori 1.6.10 Release To Correct Bugs, and Workaround Spotlight Flaws

While making the changes to Mori’s code for 1.7, I encountered some oddities in test results, and it turned out there was a bug which I had introduced in an earlier release. While it doesn’t appear to endanger data in Mori notebooks, it might not return all the results you expect in a search, or in entry summaries.

In addition, it has what I hope are a couple of performance improvements, continued improvements to Italian localization, and a work-around for Leopard’s insistence to treat non-Apple Spotlight metadata files as third-class citizens.

Normally when Spotlight discovers a file has been created or changed, it will ask the responsible program to figure out what’s inside, and feed it back to Spotlight. But one of the drawbacks to Spotlight’s design is it lacks the ability to define containers, or documents which contain logically distinct elements such as the chapters of a book, pictures in a photo album, or entries from a Mori notebook; and which can nest other containers as well. Treating a document as a single entity, Spotlight will open a document at the beginning (or maybe the place where the cursor was the last time it was open), even if what you’re looking for is somewhere near the end.

Because it doesn’t understand that a file can have distinct elements, the development teams for other Apple software (e.g., iPhoto, Safari, Stickies, etc.) came up with a scheme to trick Spotlight by creating new files with the data for those elements. So that’s how Jesse coded Mori’s behavior: duplicate the data for that logically distinct element in its own file. A separate copy of each element’s data in its own file. One extra file per element. That means the space taken up by your data is easily half again more than if Apple just added a container definition for Spotlight metadata (once for the notebook, another for the entry metadata file, and the third copy in Spotlight’s database).

But that isn’t all. While we’d like to keep all those extra files inside a notebook bundle (a directory which Finder treats as a file), because Spotlight treats a document as a single element it won’t look for those files inside the bundle. So Mori creates those files in the metadata cache folder (in your Library/Caches/Metadata folder), along with the metadata files from some of Apple’s programs. If you open the metadata folder and look at these files, you’ll see they have numbers to help Mori figure out which entry contains that data. But when you do a search using the Spotlight menu, and when you select menu item ‘Show All’ and the results are displayed in the Finder, you won’t see the numbers; you’ll see the titles for the entries they represent.

Leopard however, isn’t so democratic; which is why users where complaining about the entries when Leopard was released. First off, it ignores any non-Apple metadata files in the cache folder unless you set your Spotlight preferences to use those files. Secondly, it will ignore the title info embedded in the entry metadata file and just display the file’s actual title, meaning the number. How’s that for Apple undermining the work of third-party developers?

So the workaround I came up with is to add the entry’s title (or Untitled, if it has none) at the beginning of the filename, so you at least have an idea which entry matches your search terms.

(Thanks for wasting about a whole month total of my development time on that alone, Apple. I feel the love.)

I am, of course, more than happy to eat crow should I be proven to be completely mistaken or speaking from out-dated information. It’s easily worth it in order to improve the user experience.

Regardless of the rationale for the design decisions, enjoy, and thank you for being part of the community and continuing to support Mori!

How to Install the iPhone 2.2.1 SDK on a PowerPC-based Mac

Update: I forgot to mention that I got help from the great folks at NSCoder Nights in San Francisco when mucking about the installer and Xcode files. Particularly helpful were Bruce Spath and Dan Grover. Thanks again, guys!

Here’s how you can install the iPhone SDK for 2.2.1 on a Mac running at least MOX 10.5.5:

1. Ensure you have at least 6 gigs of disk space available. If you have tried to install the iPhone SDK on the target volume before, it may state an upgrade will be performed instead of an install. Sadly, the only solution I currently have for this situation is to uninstall Xcode using /Library/Developer/3.1/uninstall-devtools.
2. Download the SDK disk image.
3. Mount the image by double-clicking it.
4. Copy the mounted volume to a hard drive.
5. Navigate to iPhone SDK.mpkg/Contents/iPhoneSDK.dist in the copied folder and replace line 340 which should be
start_selected = "isIntel() && hasRightOS() && agreedToSLA()"

with
start_selected = "true"

6. Run the installer, selecting either the default location /Developer or another directory name if you’re looking to preserve your current Xcode installation.
7. After a successful installation, navigate from the installation directory (default of /Developer) to /Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications/iPhone Simulator Architectures.xcspec, and make the following two changes.

First, replace

{ Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: i386)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = ( i386 );
ArchitectureSetting = "ARCHS_STANDARD_32_BIT";
},

with

{
Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: i386)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = (
i386,
);
ArchitectureSetting = "ARCHS_OLD_STANDARD_32_BIT";
},
{
Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: ppc)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = (
ppc,
);
ArchitectureSetting = "ARCHS_STANDARD_32_BIT";
},

then, replace

{ Type = Architecture;
Identifier = i386;
Name = "Intel";
Description = "32-bit Intel";
PerArchBuildSettingName = "Intel";
ByteOrder = little;
ListInEnum = NO;
SortNumber = 105;
},

with

{
Type = Architecture;
Identifier = i386;
Name = Intel;
Description = "32-bit Intel";
"PerArchBuildSettingName" = Intel;
ByteOrder = little;
ListInEnum = NO;
SortNumber = 105;
},
{
Type = Architecture;
Identifier = ppc;
Name = "Minimal (32-bit PowerPC only)";
Description = "32-bit PowerPC ";
"PerArchBuildSettingName" = PowerPC;
ByteOrder = big;
ListInEnum = No;
SortNumber = 201;
},
{
Type = Architecture;
Identifier = ppc7400;
Name = "PowerPC G4";
Description = "32-bit PowerPC for G4 processor";
ByteOrder = big;
ListInEnum = NO;
SortNumber = 202;
},
{
Type = Architecture;
Identifier = ppc970;
Name = "PowerPC G5 32-bit";
Description = "32-bit PowerPC for G5 processor";
ByteOrder = big;
ListInEnum = NO;
SortNumber = 203;
},

Now go ahead and start Xcode and when you select the “File > New Project…” menu item, you should see a darling iPhone category for projects. Also, run the iPhone simulator in /(Xcode install path)/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\\ Simulator.app, it’s really mind-blowing to run it on your desktop, especially one Apple tells you isn’t able to run their iPhone SDK.

By the way, if you don’t feel like going through these steps yourself I’ve put together iPhoneSDKonqueror, an app which will handle these steps for you in a mostly automated manner. You should buy it. It’s only USD$5 and if you appreciate the ability to use your PowerPC Mac to write apps for the iPhone, it’s the right gesture to make to me.

The 21st century has barely started, and I’m already wishing it would end

Even after releasing two updates to the same app in as many days, there are still unresolved, critical issues that have to be corrected. I’m attempting to get the toolbar items and empty windows bugs fixed in Tiger, and solve some of the more blatant of the Leopard issues.

Speaking of which, I hate Leopard. It froze while I was away from my machine. Don’t just put lipstick on a pig and tell me it’s a healthier beast. Get a healthier beast.

Stacks? Pretty. (At least the grid layout. The arc toss is a hurler.) I can’t navigate through nested folders with it though. Less functional. Would I rather have prettier than less functional? Definitely not in this case.

So I rebooted into Tiger and answered some emails. I’m going to see if Thunderbird (yes, I don’t use Mail.app for real email) will allow me to link to its database in the Library (~/Library/Thunderbird) or whether it’s yet another example of me wanting to be so unconventional that I can’t get tools to do what I want.

Then I’ll head back into Leopard and add some more unit tests and debugging and hopefully get a stable update into users’ hands by morning. I’m hoping the debug suffix works better for me in Leopard than Tiger’s did.

Late Night Cruisin’

Ever since I decided to treat my blog more like Twitter, and just write micro-events rather than an entire epistle, writing either has come to a virtual standstill. (Except of course for the firestorm that has been Mori v1.6.4, v.1.6.5, and v.1.6.6 which is now undergoing 3rd party testing and I’m still trying to squash that “freezes while writing in Leopard” bug.)

Option-clicking the ‘Run’ icon in Xcode3 causes Mori to execute, then gdb starts up and attaches to Mori’s process, then Mori quits. Huh?

As if that weren’t enough, everytime gdb starts up, it spews out a lot of warnings about object files it can’t find. Like so,

warning: Could not find object file “/BinaryCache/Libsystem/Libsystem-111~176/Root/usr/local/lib/system/libc_debug.a(errno.o)” – no debug information available for “/SourceCache/Libc/Libc-498/sys/errno.c”.

warning: Could not find object file “/usr/local/lib/system/libcommonCrypto_debug.a(md2_dgst.o)” – no debug information available for “/SourceCache/CommonCrypto/CommonCrypto-32207/Source/Digest/md2_dgst.c”.

warning: Could not find object file “/usr/local/lib/system/libcommonCrypto_debug.a(md4_dgst.o)” – no debug information available for “/SourceCache/CommonCrypto/CommonCrypto-32207/Source/Digest/md4_dgst.c”.

warning: Could not find object file “/usr/local/lib/system/libcommonCrypto_debug.a(md5_dgst.o)” – no debug information available for “/SourceCache/CommonCrypto/CommonCrypto-32207/Source/Digest/md5_dgst.c”.

warning: Could not find object file “/usr/local/lib/system/libinfo_debug.a(gethnamaddr.o)” – no debug information available for “gethnamaddr.c”.

warning: Could not find object file “/var/tmp/Libm/Libm-287.1~6/Libm.build/Libm_debug.a.build/Objects-normal/ppc/scalb.o” – no debug information available for “/SourceCache/Libm/Libm-287.1/Source/PowerPC/scalb.c”.

What kind of railroad are we running here?

Anyway, at this point I’m planning on changing the file format after v1.7 ships. It’s just making it too tough to do some fixes. Mori still won’t require Leopard for some time yet, but I have to make my job, and putting out updates, somewhat simpler.

Mori v1.6.6 Clearing for Takeoff

It looks like the showstoppers which were part of 1.6.4, 1.6.5 (and even 1.6.3 counting the toolbar) have been dealt with. The latest build even seems to function normally in Leopard.

Thus, now that Leopard 10.5.1 has been released, and my Leopard install was for testing purposes anyway and not as my primary development environment, I’m going to install it and test the 1.6.6 build against it as well to make sure it still works. That is, after a stopover in Tigerland just to make sure that nothing in Leopard loused up my main volume.

The problems in Leopard appear to result, not from changes in the architecture of the Cocoa classes, but in how stringent the standards for values passed to them are, and how they deal with values which are unacceptable (invalid parameters and exception handling). Sure, code should only pass correct data all the time, but sometimes our expectations are off. Sometimes we get incorrect data ourselves (Garbage In Garbage Out), and sometimes, bad things happen in the real world in which computers operate.

Tiger used to be somewhat more non-chalant about this issues. It would ignore all but the most egregious problems, unless the programmer or the user asked otherwise. Leopard seems to be more restrictive and demanding of Mac developers and the code they write. Again, not bad by any means, except for the unexpected and the change in behavior for things that used to work before.

So, with more testing and better debugging (so why can’t I get “debug” suffix to work?!), we’ll hopefully see this occur less often in Mori’s code.

Now…back to that checklist.

In Mori 1.6.6, Windows are Still Coming Up Empty…Sometimes

Unfortunately, one of the fixes I thought I made didn’t carry over from one of the work directories (four at last count) I used to develop for the various MOX versions.

Or I was completely delirious at the time and never made the fix at all.

Whatever the cause, 1.6.6 still shows empty windows as a result of the toolbar problem. You can see when Mori gets confused by checking your console logs. You’ll see an entry like

2007-11-20 11:58:08.592 Mori[8503] *** -[NSCFArray objectAtIndex:]: index (0) beyond bounds (0)

Here’s the cause, and one of three possible paths you can take to get around this while you wait for the, hopefully finally fixed at last, v1.6.7 update: In order to improve your user experience (are you feeling it?), I wanted to move your old toolbar preferences settings to the new internal naming system. So it performs a check to see if the two settings are different, erasing the current one and copying over the new one if they are. However, if your previous toolbar had more items than the current one does, it will come up short during the compare and thus cause a Cocoa exception.

Mea culpa. Mea fixa isa cominga uppa.

    In the meantime, here are three ways to get your notebooks back all shiny and fresh.

  1. Add a bunch of extra items to your toolbar. Probably at the very beginning where they’re easier to get to and remove.
  2. Rename your preferences file (com.apokalypsesoftware.Mori.plist in your Preferences folder) until such time as Mori 1.6.7 is released and things have settled down. Or, if it doesn’t particularly bother you to personalize your toolbar again you could just delete that file.
  3. Just open all those important notebooks. Close them. Re-open those notebooks. All your data now appears because Mori has updated the toolbar info. (Or you can just do this for those notebooks you need for the moment. The fix will be released shortly…once I check a few things here first!)
  4. My apologies again to those who were alarmed at opening an empty notebook.


Mori v1.6.6 is Taxiing to the Runway

16112007

I just shipped the latest Release Candidate (Mori 1.6.6alpha89) to the beta testers, and I feel pretty certain it’s fine.

I’m about to do some final checks in Leopard (10.5.1) and may even install 10.5 again to double-check there while I await word from the testers.

I’m going to add a special dialog thanking the beta testers for their bravery and helpful comments and pointers. Not only have they helped to nail the big “empty windows” and Leopard freezing/crashing bugs, but their insights and explanations have revealed some things that I wasn’t aware of in Mori’s functionality! It should take maybe two or three days of coding and testing to add to Mori.

But it’ll have to wait as I know a lot of folks have been patiently enduring the problems in hope of a quick and stable release. So let me just thank them here for their fantastic service to me and Mori’s user community:

Bob Embry
Michael Koch
Rolf Schmolling
Joe Wicentowski

For their patient vigil and endurance, I am grateful.