In case you missed it, I released Mori 1.6.12 for users who were on Lion to deal with changes that were not compatible with previous versions of MOX. It’s a pretty substantial update, as most of the code was originally slated for 1.7. But I don’t believe many would dispute that these changes were overdue.

However, as 1.6.12 has been out for nearly two weeks, at least four significant bugs have been found which merit an updated Mori 1.6.13 ASAP.

• A crasher that sometimes occurs when windows are closed.
• A crasher in background process for Spotlight indexing.
• Documents of the previous session not being opened on Leopard (10.5.8) when Mori restarts.
• Search not functioning on Leopard (10.5.8).

Now, what is the prize for putting up with that kind of excitement? How about these new features:

• Compatible with Lion (but doesn’t yet provide for Lion-specific features).
• LinkBack-client support added. Saved docs now reload with LinkBacks intact. Select multiple LinkBacked items and begin edit sessions for them by clicking one menu item.
• Titles can now be fully displayed, taking up multiple rows in the Source and Entries lists.
• 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, the new “View > Zoom” menu (and corresponding shortcut keys), and the pinch-to-zoom gesture on supporting devices.
• The background color of notes can be changed in the font panel.
• Searches can be performed with simple partial terms or an advanced term syntax.
• Entries can be sent to Mori from the Terminal app or any shell/BSD invocation.
• Added gestural support: pinch-to-zoom for Apple devices.
• Added gestural support: swipe to navigate entry hierarchy (from any of the three main views).
• Users with a 3Dconnexion SpaceNavigator can use it to zoom the content view larger and smaller.
• Mori supports document type plugins for importing files dropped into a notebook.
• Entry icons can be customized in the Inspector.
• Added Dutch localization work by Thijs Zandwijk.
• Mori now accepts links to entries in other Mori documents dropped into notes.
• Items dragged into notes keep info related to their originating files, so you can double-click them and have them opened in their default editor or viewer application (similar to LinkBack). Changes aren’t yet reloaded into notebooks in this release. However, they will be in an upcoming one.
• Holding down the control key now creates link(s) instead of copying items dropped into a notebook.
• Updates to the Spotlight and internal search indices now occur in the background, using Daniel Vollmer’s SIWorkManager classes, so they no longer slow down your workflow.
• Status message window no longer pops up into foreground, interrupting you. It is now an activity window that you can show or hide.

Feature Improvements

• All URLs dropped at once into an entry are now accepted.
• New entries are created for every URL dropped at once into the source or entries lists.
• Added files to types of data accepted from services.
• Added code to load the default system icon for those types of documents whose icons are lacking in Mori.
• Entries can be copied and pasted in more ways, both in outlines and notes.
• Updated the General preference pane.
• Handles closing LinkBacks better.
• Added check to Smart Folders to allow matches on any or no tags.
• Better reporting of errors occurring in the Cocoa framework.
• Smart/tag folders auto-update their results when entries are changed.
• Trash folder no longer first selected entry when a notebook is opened.
• Dropping files into a notebook creates separate entries for each with the entries being either the files’ contents or a link (made by holding the control key when the files are dropped).
• Extracting an entry from a section of text will now provide a default title for it taken from the start of the text (works like dropping text into the outline).
• The sheet for titling the extracted text now displays the extracted text in a hide-able view.
• Purge data related to deleted entries when the Trash is emptied just in case “Check notebook” is run.
• Added a “Missing Plugin” message if the appropriate one isn’t found for an entry’s content.
• Warning on beta status only displayed once on newer releases for license holders.
• Crash Reporter Enhancements – Works on Snow Leopard; sends multiple reports; User-settable anonymization reporting; changed all localizations.
• Added column name for table/outline cells’ tooltip display.
• Pre-release now stores Spotlight metadata in a folder separate from the release version.
• Added critical alerts for incorrect number of internal directories in a notebook.
• Branded services menu items so Snow Leopard users can tell which ones are provided by Mori (Oneill).
• Initial credits for developers, testers, localization, etc.
• Added recording/reloading multiple selected entries.
• Added auto-display of the horizontal scrollbar in the content view when the content scales wider than the view.
• Software Update window can now be dismissed with the escape key.
• Changed the behavior of the new up/down multitouch swipe gesture. It now makes the entry which is up a level (the parent or its successor) the current entry when the sibling boundary has been reached.
• Added the missing “Actual Size”, “Fit Width” and “Fit Note”.

Now about the price change. When I started putting together some comparative feature charts as part of an analysis of the competition and where Mori stood, it was pretty plain in which areas Mori was deficient and where it excelled. It isn’t a notepad app, although you can create notebooks which are just filled with notes. Mori isn’t an outliner, although you can create outlines with it. Several, in fact, inside a notebook. The same is true for address book, todo lists, contact loggers and other apps of the Personal Information Manager persuasion.

Now, I admit Mori lacks calendar- and date-specific tools powerful enough to compete with calendaring apps like iCal and Google Calendar at this time. And it lacks the fake notebook paper look and syncing among devices (coming in Mori v1.8), but there’s a reason for that. When Jesse developed it, his focus wasn’t on making a computerized copy of a physical notebook nor replicating the stereotypical functionality of PIMs.

Mori’s minimalist interface belies the presence of a set of tools that let you create notebooks according to your own workflow needs and habits. You’re not tied to just one kind of notebook, be it a notepad, todo list, address book or what-have-you. Smart folders and tag folders aren’t a pre-selected set, locking you into what the developers decided you’re going to have. Nor is the Source List, allowing you to arrange its contents as folders only, entries only, or folders and entries, in any order and with as many columns as you like. You can even hide the Source List. The Entries List too. Give them a staggered arrangement like Mail or widescreen like Address Book. Or even hide them. Selectively.

A Mori notebook window in its default configuration.

A Mori window configured to display its three panes in its widescreen configuration.

A Mori window configured to only display its source list.

A Mori window configured to only display the entries list.

Searching for information is more powerful in Mori too. Jesse made the sophisticated language present in the search engine available right in the search field. A lot of users don’t need that level of sophistication all the time, so I added some settings which have less flexibility. But even in those settings the ability to use that powerful language is still present.

Checkboxes don’t have a set meaning. They can represent anything you want, with a different meaning for each notebook. The same goes for Mori’s tags, flags, labels, and ratings. Combined with its smart folders, there’s almost no limit to the kind of system you can create with Mori.

But the clearest example of the power in Mori is the “Edit Notebook Columns…” feature, which makes the Core Data technology underlying Mori accessible to users. Edit columns to create specially-crafted notebooks best suited for a particular type of use. For example, I’ve created feature roadmap notebooks for my products with category, priority and target columns to indicate the part of the product (eg, user interface, import/export, file format) affected by the described feature (or bug), relative importance over other entries in the same category, and the version in which it’s expected to be present; three columns which aren’t normally required in all notebooks. Or the two fields, Director and Genre, added to the fictional Mori Movie notebook shown above.

All of these factors, and more, add up to the best reason to get Mori: the ability to create notebooks that conform to your own expectations. Where you make the final decision on what works, and what doesn’t. A very valuable proposition indeed.

Well I got email up and running on openSUSE, not yet caught up with all the mailing lists, notices and junk I’m subscribed to, but I have with the customers which is most important to me.

Once I got the Linux machine working, I began setting up the tools necessary to write software for the Mac, and to incorporate into that effort the files necessary to make Mori and the other Apokalypse products run on Windows, Linux and various mobile devices.

Apple’s insistence that we must purchase new hardware every 18 months is plainly greedy, consumer unfriendly and very environmentally-unfriendly. I refuse to unnecessarily chain myself to the system as Apple chooses to package it.

I had previously decided to move onto Cocotron, a cross-platform (compatible with a target which uses a different system than the host) framework which looks and acts like Cocoa to programs using it but in a way that permits them to work on Windows and Linux, once Mori 1.7 was released. But the failure of my iMac, Apple’s policies and the availability of other growth markets have converged to motivate me to integrate it into the same effort.

But Cocotron is developed on Macs and uses toolchains (the set of development tools which builds the programs) for a format suitable for the Windows and Linux platforms. What I wanted was the toolchain for Linux that targeted MOX.

But I discovered very little practical effort was made in this direction. So to make this effort a reality, I availed myself of an open-source compiler effort, llvm, and began modifying it to be part of a fully-functional cross-platform toolchain.

But since working with Cocotron would at least initially involve running on MOX, I once again took up the effort to install Leopard on my pc as many had reportedly been able to do, and which I attempted over 2 years ago. The day after Thanksgiving Day (here in the US) I got Leopard working on my PC, an Athlon64 (Venice) machine. Details of the process and required kexts coming in a follow-up entry. (Thus I didn’t need to relocate to Miami. At least not yet.)

I wasn’t able to migrate the stuff from my previous Mac work drive due to space limitations, so I decided to postpone the MOX situation until after I could clear up more drive space and install Snow Leopard. I resumed work on the cross-platform toolchain and once I got it to produce what might be compiled files suitable for the Mac (at least according to the Linux utility “file” which identifies them as Mach-O object binaries) I decided they needed to be tested in the Mac (Darwin) environment for validation and to complete any unfinished details for a working cross-platform clang-based toolchain. (I’ll write an entry and submit patches back to the clang project if successful.)

By this time I had already purchased a copy of Snow Leopard after the Tuesday, November 30th meeting of the North Florida Ruby Brigade (a great bunch of guys with a penchant for more than just Ruby-related tech. I really hope we can help achieve a critical mass for a high-tech community in the Big Bend area), so I set about researching to what extent it was possible and what was required for my four year-old pc.

Not much, as it turns out. I’ll post an entry with details on it later, but a lot of the online info is very obsolete. The work of those in the OSX86 community and the guys of Voodoo Labs has been outstanding in making installs quite simple these days. Install Chameleon, install MOX, replace the standard kernel if needed, and install kexts for your machine if needed.

So Snow Leopard booted on my pc yesterday, and finished migrating my data (more or less) today. It took less time to install SL on a freshly-formatted drive than it took to migrate my data (no way to skip the directory on my hard drive holding my music files? Really?).

There are some things I’ve yet to work out, but I can at least continue developing for Macs. I’m currently unable to test on PowerPCs and Tiger, which I will correct with replacement hardware eventually; but at least Xcode still builds apps for them.

Xcode is running well (apparently). I’ve compiled Mori and some other projects, and finding some of the SL-related problems users have complained about. I’m trying to fix those up for another Oneill release today. But whether I can correct all those bugs beforehand or not, there will be a new snapshot to see if this set up actually works.

One thing I can report after using a current Linux system during this time, which was evident even within a day, is it will in no way become the preferred desktop platform for users who regard computers as a tool for other work rather than a gadget to be played with for its own sake.

My sincerest apologies to anyone attempting to contact me recently. Close to two weeks ago, my iMac G5 began to shut itself off. What happens is that as it boots, sometime after loading its kernel extensions, it will power itself off. This has happened a couple times before, but not as long as this time. The last time, it had just turned Spring. Now that it happened when the cold weather set in here in North Florida, I suspect its climate-related. I plan on relocating to South Florida at the end of the month in hope that it will correct this problem, but it’s no guarantee that it will.

In the meantime, I’m using an old PC running Linux to access the Internet. And I’m really annoyed to find that a lot of sites have some terrible incompatibilities with five year-old browser technology. I cannot access my email, nor my Twitter nor Facebook accounts. So there’s now a customer service phone line, (626) 667-4285, for you to reach me in addition to leaving comments on this blog or the user forums. For now, these are the only means I have to respond to anyone’s attempts to contact me.

I’m attempting both to fully upgrade this machine to current versions of Linux and get a working installation of MOX so I can continue work on Mori for a release before the end of the year. I apologize for the inconvenience in delays once again, and will provide additional information as the situation improves.

Back on August 27 of this year I stated the release of Mori 1.7 was imminent due 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.

As you can see, another bevy of announcements all bunched up in one. Did you feel like it was time to unwind? Nope. Me neither!

First off, an announcement that I put off while other things had to be wrapped up: Apokalypse Software Corp. has acquired the rights and the code to bitShifter, the file encryption utility initially developed and marketed by MemSculpt and then ForgEdit. As with prior acquisitions, the current licensees’ purchases will be honored, updates will be made, etc. I’m still trying to understand what some of these licenses were (perpetual what, now?), but they won’t be problematic as the key is in gaining more licensees rather than bleeding the current userbase dry with the nickel-and-dime tactics I despise so much.

However, the name and logo will need to be changed, as the original developer cannot relinquish them…or something. (bitShifter is vague and ambiguous or too techie sounding, anyway.) It is being revamped, and will be re-launched shortly as an Apokalypse product. The price will likely remain $99 USD if I can figure out what type of license that bought. (Perpetual what, again?)

Now that Apokalypse has encryption technology, I’m putting Mori 1.7 out with encryption ASAP. Unfortunately, this means some of the really cool features I originally planned to incorporate in the release will be delayed until 1.8, including enumerated entries, and continuous text. What’s still in? LinkBack, customized labels, font settings for source & entry views, better keyboard navigation, outlining improvements, self-downloading updates, and now encryption.

I’ve also gone over the features of quite a few of Mori’s competitors, and realize how undervalued Mori is. So I’ll be creating a version with fewer capabilities at the current price to stay at the lower end, and the price of the full-featured version will be raised to $99.95 USD. On top of that, a Pro version will be released at $199.95 USD. Mori licensees will automatically be bumped up to the Pro license when the update is released; so as I promised you before, you won’t have to pay extra for the 1.7 upgrades. In fact, as I’m still planning to put out a 1.8 release, current licensees won’t have to pay for any 1.X upgrades.

Next on the list is the big project I had been working on when I purchased Mori and Clockwork from Jesse. It’s a programming system based on the Smalltalk programming language and it’s called Cocoalogue. What’s so special about it? It’s an interpretive system, with programs written in a shebang-prefixed text file like most scripting languages available on UNIX-like platforms. The Smalltalk-based syntax is virtually identical to Smalltalk-80 with extensions for declaring classes, methods and data types (with strong- and static-typing). It supports dynamic run-time features including blocks, automatic garbage-collection and data translation. And it has, as the name Cocoalogue would indicate, a bridge to Mac’s Cocoa frameworks. I’ll go into greater detail on these features and Cocoalogue’s current limitations in my next post. This product hasn’t been released yet, and will be priced at $129 when it is.

But I’m making the announcement now for a very good reason. You’ll be able to get a licensed copy of Cocoalogue today before it’s made available anywhere else, including the Apokalypse website, through the PMC Software Build Your Own Bundle program. Seth Dillingham, another indie Mac developer, has put together a special bundle where you can purchase Cocoalogue, Mori, Clockwork or a family pack at discounted prices. You could even get a discount on over 120 other fabulous programs from Mac indie developers as well! Not that you want to.

So go on to the bundle site, remembering that it’s the only way to get in on Cocoalogue now, and for the substantial savings you’ll get on Mori Pro 1.7 by getting a Mori license today.

And don’t forget: these sales are going to fund cancer research and treatment, so please don’t be stingy on what are already terrific deals. A lot of folks are counting on you!

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.

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.

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!

When I purchased Mori, one of the first things I did was generate some documents about its codebase. For this, the main tool I used was Xcode’s Class Model tool to generate charts of the various classes involved. I spent several days laying out the classes on the charts, then printing and then folding and taping the pages together. (This is a process which I am replacing with specific related classes that occupy only one or two pages, so I can keep them in a notebook; or sending a PDF to Kinko’s the next time I need to print the whole chart.) They helped me get an understanding of how code was laid out, and their relationships.

After a while, the tape that held the charts up on the wall would lose their adhesiveness and down they’d come…again and again, eventually falling into disuse. Having gotten a digital camera, I spent a day reassembling the crumpled remains of the charts about a week or so ago, and snapped a few shots which I present here.

There are 33 classes, and 25 protocols defined for the document back-end plugin, and quite a few supplementary category methods extending Cocoa’s foundation classes.

The user interface plugin has 85 classes, 18 protocols, and its own quantity of supplementary category methods.

At least, that’s what Mori’s classes looked like when the shots were taken. Today it looks a tad different.

Oneill, the branch for Mori 1.7 is under active development again and will bring substantial changes to the UI and back-end architecture. You shouldn’t notice any hiccups in the file format, but you should see better functionality and performance.

At least that’s what the testing support should help me do. Thankfully, I make heavy use of the Subversion SCM system. Just in case.

While trying to solve a user’s problem with an mGTD script, I came across a subtle issue that demonstrates some issues that arise when violating a programming philosophy, tackling bugs in other people’s code, and general uncertainty whenever coding in AppleScript.

Working with AppleScript is generally considered iffy, because a lot seems ambiguous and so much is dependent on how the dialect is interpreted and how scriptable apps handle some of the application events which scripting is dependent on. I’ve written scripts before, some I’m pretty awed by (that it works, actually, but also what it does), but I’m still hesitant to tackle some scripting issues. In addition, being a GTD greenhorn, and an mGTD noob made trying to respond to this issue authoritatively very questionable.

Thankfully, BMEGuy, mGTD’s author and all-around community nice guy, tackled the question with a quick solution. But the updated script was still problematic, and so I felt I really needed to participate in coming up with a solution.

Again, being an mGTD noob and all, it took me at least half an hour to figure out how the plugin worked, and the script on top of that. Then, after I was able to get the script to run, it worked for me. Hmm.

But that’s because I was testing with an entry with a date due of today. Once I switched it to later in the week, the entry was still showing up for today. Isn’t that odd? It seemed I had inadvertently left in the date line from the original script. When I removed it, I witnessed the same problem.

It turns out there’s a bug in MOX 10.4.11′s iCal 2.0.5 (I’m guessing it’s present in earlier versions as well) where it doesn’t properly update the calendar display for new events made by the script. You won’t see it in the monthly view. However, you might notice a little oddness in the weekly view.

You can see the event if you add ‘show theEvent’ after the script makes a new display alarm for the event (between the 2nd and 3rd ‘end tell’ up from the bottom). This will display it’s properties in the info drawer, but you won’t see the event anywhere on the calendar (in either week or month view) until iCal is restarted.

Running the script in monthly view doesn’t show any artifact in the calendar, but the data is shown in the info drawer.

You could also run the script in the weekly view and then switch to the monthly view, in which case you get this:

So now that the question of the event’s presence in the calendar was settled in my mind, I had to figure out why my faulty script displayed the event, but not the proper one; and how to coax iCal to display it.

Being unfamiliar with mGTD still, I tried to figure out the difference between the attribute name “dateDue” and due date. due date is one of the standard properties for entries in a Mori document. attribute name “dateDue” is a user column added in the example mGTD notebook. You can view them all the user columns by selecting the menu item Edit > Edit Notebook Columns…

Okay, good so far, but why would one cause iCal to display properly and not the other? After moving the due date line about for a while, I checked Script Editor‘s Event Log, and saw

The event reply for the due date had a missing value! Mori wasn’t returning a value for the due date property because it wasn’t set (and wouldn’t be in the example notebook). Now I had to find a way to use one of those missing values to make theEvent visible without setting it to the wrong date. And the problem with that is most of the properties used in Mori’s entries aren’t appropriate for an iCal event.

I eventually thought about re-ordering the messages to iCal instead of being so fixated on a change in the messages to Mori or playing with the properties being set in creating the event. What I came up with was a plan to use the messed up missing value date as before to make the event visible first, and then set the date correctly. The code turned out like this:

tell application "Mori"
	tell current entry
		set theDate to (get attribute name "dateDue")
		set faultyDate to due date
		set theName to name
		set theNote to note
	end tell
end tell
tell application "iCal"
	tell calendar "Scramble" -- the user should specify the name of the target calendar here
		set theEvent to make new event at end with properties {description:theNote, summary:theName, start date:faultyDate, allday event:true}
		tell theEvent
			make new display alarm at end with properties {trigger date:theDate}
		end tell
		-- show theEvent
		set theEvent's start date to theDate
	end tell
end tell

And to my surprise, it worked! So as I began gathering the materials together for my reply to the issue, I noticed something in the event’s info drawer that had escaped my attention before:

iCal, that’s just crazy talk! But at least it would explain why it would display traces of an event, if anything at all; and why it wasn’t noticeable earlier: iCal would correct the event data when reading it in when it started (“iCal database, that’s just crazy talk!”). But somebody forgot to add a sanity check when creating a new event from the properties passed to it by our script. (This is an example of why the Once and Only Once principle should be heeded. If there’s only one place where events are synthesized from pre-recorded values, whether those values are from a stored file, a script or the UI, then all those code paths will benefit from any sanity checks added to event creation.)

Knowing this, here’s another means of working around this bug, by sending iCal info that won’t confuse it:

tell application "Mori"
	tell current entry
		set theDate to (get attribute name "dateDue")
		-- set faultyDate to due date
		set theName to name
		set theNote to note
	end tell
end tell
tell application "iCal"
	tell calendar "Scramble" -- the user should specify the name of the target calendar here
		set theEvent to make new event at end with properties {description:theNote, summary:theName, start date:theDate, end date:(theDate + 1), allday event:true}
		tell theEvent
			make new display alarm at end with properties {trigger date:theDate}
		end tell
		-- show theEvent
		-- set theEvent's start date to theDate
	end tell
end tell

Thinking about these two solutions it’s clear that picking the latter one, with well-formed properties, is the safest choice to make. Here’s additional proof: the first solution, the one which plays with the start date to make the event appear, will indeed make the event appear. But if there’s less than 24 hours until the event begins, it will appear on the wrong date and still require iCal to be restarted to appear in the proper location!

It just goes to show you, while you might be able to get away with just the barest minimum, and someone else might normally clean up after you, it’s best if you did the job correctly from the start in case your safety net disappears from under you.