I know I’ve been a little “quieter” than usual lately, and I figured it was time for an update as to what’s been going on.
First — I’ve been really pleased with the success of MultiMarkdown Composer. Thank you to everyone who has been so supportive! It’s been an interesting project to work on over the last 8 months, and it’s still my go to app for writing MMD text on my Mac. Thanks to the feedback from users, I have found a few more bugs that I am working on fixing to try and continue to make it the best environment for working on MultiMarkdown documents.
Unfortunately, some of these new bugs are arising out of workarounds I had to try in order to make some features work on OS X Lion. Specifically, the ODB Editor protocol support. Without getting too technical, depending on what path Apple takes in the future with the App Store and with sandboxing, ODB Editor’s days as a protocol may be numbered. The more I learned about it, the more I realized it really is an unnecessarily complex protocol, and a much better approach (IMO) is used in nvAlt. The nvAlt approach doesn’t require any special programming in the text editor, only in the application that wants to be able to send text out for editing. It seems to be Lion and sandboxing safe, and is worth looking into as inspiration for a successor to ODB Editor.
With all of this, I am not certain whether I will be able to continue to support the ODB Editor protocol properly in future versions of Composer. We’ll see what I can work out.
A bigger issue, however, is going to be ongoing support for OS X 10.6. Lion has been available for almost as long as I’ve been working on Composer. There were a few bugs in the early versions of Lion, but I’ve been running OS 10.7 on my primary machine now since November. And I really like it. I’m sure there are still a few apps that are not compatible, but all in all it’s a great update.
The reason this is important to MultiMarkdown and Composer is that I learned a lot while creating MMD Composer. I learned about some things that worked well, and some things that still had room for improvement. I’m taking what I’ve learned and trying to rewrite a new set of tools to make MultiMarkdown documents more accessible to Objective-C programs. Specifically, my goal is to abstract as much of my work on Composer as possible into code that will work on the Mac, as well as on iOS.
And it’s going really well.
Since December, I have been playing around with a MMD-based iPhone and iPad app that is basically a plain text editor for notes (like many others out there), but with the ability to export HTML, LaTeX, and OpenDocument right from the iPhone. With some Dropbox trickery, one can even use the LaTeX to create a PDF with the help of another machine (still no LaTeX support for iOS, and that is not something I’ll be taking on).
That was useful, but not all that revolutionary. It’s not something that is ready for public release.
What’s been really interesting is the work I’ve been doing in the last few weeks to get a live HTML preview feature that actually meets my expectations. Sure - other apps out there have a “live” HTML preview feature. It’s trivial to put up a WebKit window and display the output from Markdown or MultiMarkdown in it. It’s trivial to have scroll bars that let you scroll up and down the preview window. And Marked has definitely upped the game with lots of other features.
But what I really want is the ability to work on longer documents, easily navigate the structure of my document, and have the HTML preview window keep up with what I’m doing. The other “live” previews that I have tried begin to bog down as documents get longer. The performance hit begins to make the editing window feel sluggish. These previews work really well for short documents (e.g. blog posts), but don’t work as smoothly for longer documents (e.g. the MultiMarkdown User’s Guide). I’ve come up with a few “tricks” that let me improve the responsiveness of the interface so that your editing window is as responsive as possible, and the preview window is able to keep up pretty well so that you get a better idea of what the final result is going to look like. I still have a few things to work out with this approach to try and make it even faster, but it’s much better than anything else I’ve tried for longer documents.
Getting back to Lion — as I rewrite this interface code, I’ve begun using code that requires OS X 10.7 to work. I’m not yet at a point where I can pull this code back into Composer yet, but I’m worried that when I do I might lose support for 10.6.
I have not made any decisions yet, but it seems that I might have to choose from among the following options:
Split the new code into a new project, and keep Composer as is for 10.6 support. This would require providing bug fix support for at least 2 Mac apps, as well as the iOS app. As Composer and the other codebase drifted further apart, I would be worried about the feasibility of this. Additionally, it would be unlikely that new features would make it into Composer, which doesn’t seem right for an app that’s only 4–5 months old. And while the new features are headed down a different path than my original vision for Composer, I’m not keen on requiring users who supported Composer to then be required to buy something else, unless it really is a different application. I need to look more into exactly how the App Store works, but I don’t believe it would be possible to “grandfather” current Composer licenses into the new app, while still keeping the old version under development.
Once it’s stable, migrate the new code base into Composer, adding the new features, but ending compatibility with 10.6. I’m not thrilled about the ramifications this would have for 10.6 users who have just purchased Composer. It would obviously still work, but they would be unable to update to newer versions.
Try to separate out the parts of the new code that require Lion, and try to keep one application for both versions of the OS that have a different feature set. The main problem here is that the changes that require Lion are pretty fundamental and are going to be used all over the place (e.g. the use of
NSRegularExpression). While nice in theory, this could become a maintenance nightmare, and could actually reduce the functionality available on 10.6.
Again —- I am still in the early stages of thinking about this, and welcome feedback. My rough game plan for now is along the lines of:
Continue working on the revised code base to make it as functional and compatible across Mac/iOS as possible
- While also continuing to fix known bugs in the current version of Composer
Use the revised code to create a Markdown/MultiMarkdown focused iOS editor with features and performance not currently available
After having a chance to further revise the new code, look at integrating it into “Composer 2.0”. At this point, I’ll have to decide what approach to take for the future of Composer. It’s very possible that Mountain Lion will be available at this point, and it wouldn’t be unreasonable for future versions to only support the most recent 2 versions of the OS. We’ll see.
I just wanted to give an overview of what’s been going on around here lately, what the future might hold, and the potential issues that might arise in the future. As always, feedback and comments are welcome.