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.

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.

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!

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.

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.

I had hoped for a quick release to get the fix out to those who are upgrading now (particularly from older, Hog Bay Software versions), but I had upgraded my Xcode installation mid-stream, which is generally a bad idea if you can’t test the effects a tool migration will have on your projects. And Mori is quite unique in the way it’s constructed, being almost entirely plugins, and plugins which run plugins.

It took a week to resolve unit testing problems, some of which were due to Mori’s unique project files, some of which were due to changes in the layout of Xcode’s tools directories and one due to a bug in the unit tests for the ‘Check and Repair Notebooks’ functionality (which I wasn’t going to risk going out with a bug whose cause I hadn’t determined).

Anyway, testing problems aside, I’m packaging the latest for release now. You’ll be able to read the release info shortly.

There is a fresh bug in Mori v1.6.8, so this one now in testing may go official without all the features I had promised, but I’m sure you’d rather have it lacking those features and working than to use the buggy version and wait for all the new fixes to be incorporated in v1.6.9.

Speaking of new fixes, I might add some more drag and drop capability as the lack of dropping groups of files, or folders, or even JPEGs into the source and entries view is seriously hampering productivity for a lot of us.

Anyway, we’ll see how this test version works out. I’ll try to add those other fixes, but when the latest incarnation of the empty window bug is fully squashed, I’ll release it with whatever fixes are completed and begin adding the rest to v1.6.10.

The fixes include:

• Rewrote user settings handling subsystem (to prevent wayward settings from affecting other operations).
• Improved notebook check and repair functionality to fix orphaned entries and entry data records.
• Fixed stall when dropping items into Mori’s source or entries lists.
• Fixed (or at least improved) Italian localization.
• Fixed faulty version update notification.

The code I had hoped to incorporate into the update, but which didn’t make it (because it was already three weeks or so overdue) included fixes for Smart Folder Rules, non-wildcard searches, and word-count bugs, which are among those to be included in v1.6.9. Also to be included are user-settable font settings in the source and entries views, and the fix for the font prefs for notes.

Work on v1.6.9 has already begun, and my work in v1.6.8 improved the ability to perform testing in new releases. The Beta Test Gang will find the first test version on the site Jan 2nd.

The debugger is failing in the middle of an initializer method (self becomes 0×1, and the argument becomes invalid), which typically indicates an invalid pointer, but I’m just using -[NSCharacterScanner scanInt:], which shouldn’t be so problematic. (But it is, after all, Cocoa.) And it turns out that isn’t the correct tactic to use anyway as I want to extract info from the internal version number (MMmmb.bs.rr), not the public (MM.mm.bb[s[rr]]), and Cocoa doesn’t have an API for handling fixed-length records. (Possibly the only functionality from COBOL I actually miss! I mean, there are BCD libraries for C, right?)

So I’ve spent much of the day tussling through docs and links for various RegEx frameworks for Cocoa, and trying to add RegexKit to the Blocks plugin framework; first 0.5beta and then 0.4beta via compilation. Now I’m attempting to use the prebuilt binary, which is problematic because frameworks are normally used by applications, not plugins, so it doesn’t exactly fit right (or run). But as the clock’s been ticking, it looks like it’s time to punt and attempt another tactic by hard-coding a parser for the internal version scheme or using defaults for the optional fields in the public version scheme.

This is just to fix the bugs in the version class I added in an earlier version, which I have to get out of the way to continue fleshing out the revamped defaults system I created with unit tests and component code in order to release! Argh!

It hasn’t been all sweat and tears, though. I went through a period of idea generation (both software and marketing/entrepreneurism) early during the process and also, last night as I was organizing several years of accumulated papers, bills and what-not, found several new UI ideas I had come up with (and forgotten) and the missing FreeHand install CDs.

Now to get these final PITA problems licked so I can continue to move Mori forward!

One of the goals of this version is improved recovery from faulty stored values relating to the preferences and UI, so you can continue with only minor inconvenience and perhaps a need to again set preferences to your liking. Not adequately performing this resulted in some of the missing toolbar and empty window problems that were experienced before. (For a more exciting example of cascading faults, read about the 2003 Northeast blackout.)

So after some delays in getting the unit tests for this new component to execute properly, I’m now adding that component into the program. Once I have the Cocoa preferences system replaced, I’ll be releasing 1.6.8. Then I’ll work on the possible fix for the SpotLight ‘odd name’ bug for a quick-turnaround (later today) 1.6.9.

If that particular bug can’t be quickly fixed, I’ll work on some other long-standing issues in Mori for an update that will be released after a few days.

Incidentally, Tobias had a valid concern regarding the update process: “Where does testing feature in this? In olden times an update was a build with only known problems since a few people played with it for a week before it was awarded a version number. WebKit offers a choice between bleeding edge nightly r1234 and release 3.0.”

I plan to continue to rely on the Beta Test Group for testing updates, with a release candidate at least one version ahead of what is shipping. However, at the time of this writing there are 320 open bug reports for Mori, even after having pre-release testing candidates as part of the process. That just isn’t right.

I’m primarily depending on the unit tests to prevent shipping defects to you. They serve to expose bugs in existing and new code; and by adding tests for the types of bugs identified in the bug reports, the tests will continue becoming more valuable to the release process.

The purpose is to continuously speed up the process by improving its results. It shouldn’t be a shock when a program works right off the bat. The delays are (partly) associated with having so many steps of repeated inspections on the same system. It multiplies the time it takes to get a new release out the door. The less I tolerate it, the quicker it gets done correctly.