Status Update
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.
Follow me on twitter
Subscribe to atom feed
Old Comments
At the risk of sounding selfish (but balancing with the fact your time is limited) IMHO just move on to Mountain Lion and don’t worry about back support for Snow Leopard on back. I’m guessing the majority of people using the older systems are doing it for a reason and are typically expert with their systems, and could use alternatives to Composer for MMD work. I doubt cost is an issue, as the Lion update was only like $30? So I “vote” for 10.7 and up, keep it simple and keep Composer moving forward, not backtracking.
As far as iOS there are already quite a few mmd editors. The breakthrough for ipad is like you see, a port of latex. But until that happens I don’t see much call for this. If you are desperate for an iOS equation there is a tex equation app that could be useful (kind of like latexit).
We are all glad you are keeping busy moving MMD forward.
Thank you for your support and for your thoughts about Composer.
As for iOS:
1) To my knowledge, there is no MMD support on iOS, just Markdown. For most people that doesn’t much matter, but for some of us it’s a critical distinction.
2) The apps that support MD don’t really do a very good job and are pretty limited, IMO. There are still a few existing apps that I need to check out, but the ones I have tried generally suffer from one or more of the following:
If you’re only using an iOS app to write a couple of paragraphs, then I agree that most of the apps are probably fine. If you want to work on longer documents (especially those that take advantage of MMD’s advanced features), I have yet to find anything close to what I’m doing now (and my app is still in development.) But just like Composer, not everyone needs (or cares about) some of the more advanced features. And that’s fine - my goal is not to push out competition. It’s to create software that fulfills my own needs, and to share that with other people with similar needs. Users who are content with what they already have should stick with what they are using.
But yes - a version of LaTeX that actually ran on the iPad would be a real game-changer for my own MMD use. But until that time, there are still some other options…. ;)
I’m with Bob on the Snow Leopard issue. I’ll be announcing soon that Marked is going Lion+. I just do not have the dev resources to maintain compatibility.
There will be a small but loud outcry, I’m sure, but like you said: my goal is “to create software that fulfills my own needs, and to share that with other people with similar needs.” I’d rather focus my energies on that than on debugging on a 5-year-old mini running Snow Leopard.
I’m working on a long list of separate documents with Multimarkdown (or - at least for now - the subset of it that Kramdown can convert to HTML).
However, I now use my iPad for this, as well as TextMate. I started with Elements (just Markdown, and throws occasional errors) and am now using MarkNote. Brett Terpstra’s crowd-sourced list of iOS editors omits an mm filter, so I’ve had to do my own searching).
If it helps with future direction, a good iOS mm editor is/has:
I’d happily pay more than the usual tiny iOS app amount for this. I hope someone makes such an app, because I can’t.