This article on the importance of bringing a topic focus to the news is very important. The thesis is that the article-by-article nature of modern news is incapable of covering issues on any but the most trivial of levels, since every (short) article needs to start from scratch.
If you've felt like the news media can't ever seem to get past the first couple of days of Econ 101 (or other equivalent topics), this is why.
Blog of interest: Expanding Brain (ExBr), a blog about "Windows outliners, software development and starting a new business". Also of note is that the author has set up a wiki for outliner topics.
The author and I have been exchanging emails, comparing development notes.
I finally have a job, a real job, though I don't start until May 9th. For a while after that I will have an overlap between my real job and my last contract job, but after that, I hope to finally have some time to spend with a clear conscience on my open source projects that I want to work on, especially Iron Lute which has been seriously neglected (though not quite ignored).
Frontier will apparently be open source in the near future. I've actually spent a significant time with the product, and I have an interesting perspective on this issue as I have a project started in no small part because of the closed nature of the Frontier code. (A project, I might add, that I really, really, really wish I could get back to, but a guy's gotta eat.)
So I ask myself, as someone who might be interested in developing the product, what does an Open Source Frontier bring to the table?
Well, Iron Lute is getting firmly placed on the back burner, 'cause I've been laid off my job and I need to concentrate on things that will make money. I do intend to get back to it but I have no idea when that will be.
Today's post is about one of the little libraries I'm developing as part of Iron Lute. In the previous posts, I've laid out what I believe were successes; today I highlight what is so far a failure for a change of pace.
Please note that today's post is really more of an XML post then an outliner post; if you're interested in programming with XML, stay tuned. If you're only interested in outlining, you should probably move on.
Dotan Dimet has some comments on Iron Lute, which I think contains some misunderstandings about Iron Lute that mostly stem from the developer-centric view of Iron Lute y'all have seen so far. I posted a comment containing some follow-up on his post, and I replicate it here for posterity and RSS readers. Note it contains links to some of the actual code which I posted to provide evidence of how hard it will be to provide bi-directional text support in Iron Lute, so if you want to see some of my actual code, now's your chance.
I have a case of the multi-disciplinary writer's block. I'm having a hard time writing the outline saving code in Iron Lute. I have an essay I want to post here, but it is obstinately refusing to go into focus. (I may yet just post it in a nebulous state, as I'm not convinced it's ever going to focus, by its very nature, but I think it's important that I write it.
Just a quick note: I'm still working on the XML save format for Iron Lute outlines. I'm trying to use a library I've put together for XML serialization and it's not going so well right now. I think it still has potential but I may need to re-work it into a "version 2", because version 1 is sucking pretty badly.
In my previous post, I discussed the practical matter of how to hold the outline structure we've built so far together. Having created a strong base, it is now fruitful to consider how to extend the data structure to handle the wide variety of outline structures I want Iron Lute to be able to manipulate. Node Types
One of the most interesting possibilities inherent in this structure is to formally recognize that there are a lot of potential different types of nodes that can be built.