Leo and Iron Lute
Rand Anderson blogs about Iron Lute and his preferred outliner Leo:
Seems he's aware of Leo (my outliner of choice) but wants an outliner that allows the use of the outline structure for all content (as opposed to having a body for free text associated with each tree node, as Leo does).I'm pretty committed to Leo and it's author's vision for Leo going forward, but Iron Lute is worth keeping an eye on.
First, thanks for the nice comment ("worth keeping an eye on").
Since someone's interested, I thought I'd talk more about why I didn't start by extending Leo.
(Protocol note: When starting an Open Source project, the first responsibility of the starter is to determine why existing projects aren't worth building off of, so I believe it is necessary for me to justify why I don't start with existing projects.)
Basically, my "problem" with Leo (as in, "the reason I didn't just build on that instead of writing my own stuff", not an actual "problem") is Leo is really an application of an outliner, not an outliner itself. Leo is using an outliner to track the little fiddly bits that constitute the pieces of whatever it is building (program, website, etc), but you can't actually use the outliner to write text in the "outliner" itself.
By "outliner" here I specifically mean just the part of Leo in the upper left window, not the program as a whole; you might think of it as the outline widget only. I think the reason for this is the aforementioned difficulty of writing an outline widget with open source widget sets, and Leo's author is more interested in Leo qua Leo then the outliner itself (which I respect completely), so Leo's outliner is highly focused, gets the job done with relatively minimal attention to outlining (as compared to the gyrations I'm undertaking, not saying that it was trivial to write per se), and not usable in the general case. For instance, try to write an essay in the upper-left window alone; it's not convenient.
In programmer parlance, Iron Lute and Leo are almost completely orthogonal. Despite the surface similarity they are actually quite different projects that share little in common.
Forgive my splitting hairs like this ("outliner" vs. "using an outliner") but it's an important ability for a programmer.
As I further develop the outline model you'll see why it's a very different beast then Leo. In the far future (year+), I hope someday that Leo can use Iron Lute as a display library for their outlines, as I mentioned on that page. Then Leo can get for free/cheap all the other stuff I'm talking about, and other exciting things I will talk about later that I'm sure Leo would just love to have in place.
It should be very easy to put them together; both are Python/Tk. Leo's use of Tk didn't really enter into my decision to use Tk, but I consider it a happy side-effect. Ideally, you need not lose your "commitment" to Leo to continue to be interested in Iron Lute. It is an explicit design goal to make anything doable with outlines possible with Iron Lute, so I will have no objection to Leo specializing Iron Lute in whatever manner is necessary to maintain Leo's conceptual integrity; I'm fairly confident that the structure I'm building will be flexible enough to accomodate what I've seen of Leo with no compromises on Leo's side.
I haven't contacted Leo's author about any of this because let's face it, right now Iron Lute is vaporware to everyone but me. When I have an actual release it might be worth discussing. In the meantime it's not worth bothering him with unless he finds it himself.
Disclaimer: This may sound presumptuous, as if I'm "planning" something for somebody elses project. First, I'd like to disclaim that, this is just something I see that could be beneficial for both parties. Secondly, integration with Leo would constitute a "significant contribution" to Iron Lute that would allow it to get to Open Source status under the license rules I posted earlier, and as both would then be Open Source projects under compatible licenses, anybody could do it without "permission".