"Distractions" post on Iron Lute

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. Comment I posted follows:

"Iron Lute, on the other hand, looks like another case of someone falling in love with the technology...."

I strongly disagree. Iron Lute is being created because there is no good platform to create LEO on. LEO is, with all due respect, a hack with regard to outlines, in the sense I can't build anything interesting on top of that, other then LEO. I don't care about outlines intrinsically and I look forward to the day I can actually do things with them. If a good platform existed (in a reasonable, non-Java language) I would have used it in a heartbeat. Unfortunately, no such open platform exists.

I think you'll see that even in the initial alpha release, the user focus will be on "what you can do" with Iron Lute, and not just "the outliner" aspect of it. Remember what you're reading now is developer documentation, not user documentation. That's waiting until closer to the release.

"Pity he's making the same mistake (well, "short sighted decision") made in Leo by choosing a GUI toolkit that doesn't support BiDi."

Only Tk has had the flexibility to do what I need. Text widgets that support BiDi don't support other things I absolutely need (like "how big is this text, wrapped?") so unfortunately they are not on the table. Tk would have been nearly my last choice, but it's the only one that worked.

(At least Tk supports Unicode!)

Even the Tk widgets aren't ideal and need a lot of massaging to work right. How much massaging? Let me show you ;-) Here's the code for each node in the outliner, and here's code for the outline frame that ties them together into an outline. That's 70 KB of Python code (using a conservative *3 for C/C++ code, that's 210KB, bigger then many novels), and it's still incomplete.

The GUI is abstracted from the code so if GTK or QT ever get their act together relative to my needs it would be relatively little work to get the support in there. (I actually started some wxWidgets work on Windows but I couldn't make it work without intolerable flashing, even after I hacked on the C++ code of wxWindows itself. But it was far enough to show the separation works.)

The other problem is that I have to do all the geometry management of the nodes myself, so BiDi and other issues are going to require a lot more code then in most projects. A lot of very, very sensitive code. See that stuff in outlineframe.py, like the syncWithDocument method or moveCursorToWidget? All very touchy, all needing to be modified for BiDi. Unfortunately, and I really mean that, it's not just flipping a switch in the code, even if GTK gives me what I need :-(, it's a massive and bug-prone re-write of the GUI guts of the project.

The good news is that it should at least be possible someday.

I'm going to link to this on my 'blog, as long as I've decided to share some of the code might as well do it for everyone ;-)

Which I did.

Thanks for the commentary and feedback. I hope this doesn't sound hostile, because misunderstandings about the nature of Iron Lute are entirely my fault, until it is released and can be actually used, so I don't "blame" Dotan Dimet for anything and actually value the chance to explain myself more clearly.

A stronger focus on "what can we do with the outliner?" will become evident when I start talking about how I've abstracted saving and loading from various formats and various file-like things, and it will become more clear how Iron Lute's focus is on the user, not the technology. (It's just that you can't skip the technology step, unfortunately.) The power of loading and saving OPML(or any other supported format) to various sources, not just files, will be clear. (For example, I already support loading and saving OPML to and from Manila sites, just to make sure the support was working and useful.)

Minor update: It occurs to me that it is worth mentioning why I tried wxWidgets on Windows. It turns out that only Windows has a rich text widget that you can ask, "Given the width you currently have and the formatted text you currently have, how much vertical screen space do you need to completely display the text?" This is very useful in many circumstances. Unfortunately, the rich text widgets had too many other flaws for what I needed to be useful, including but not limited to excessive flashing that I couldn't stop (even after trying every permutation of "double buffering" flags the widget supports), fears of massive incompatibilities due to there being at least 4 distinct versions of the Rich Text widget with no way for me to ship the one I need, and inability to control or even detect certain keypresses that are built-in to the widget (for example, I couldn't detect a "CTRL-+", which increases the size of every font in the widget, which in the outliner would require re-sizing the text widget itself; I'd either want to catch that event or prevent it, but I couldn't do either). Any one of them was a stopper; together they led me to believe Iron Lute isn't ever going to be feasible in Windows without writing a complete text widget from scratch, which isn't worth it to me. (Note that Tk is a complete text widget from scratch, it doesn't use Windows code to draw except for font rendering, and I've had perfect luck so far programming in Linux and having it work perfectly in Windows. Windows even looks better since it gets anti-aliasing the Linux Tk does not.)

As far as I can see, neither the Windows rich text editor, nor the Macintosh rich text widget, nor QT, GTK, FLTK, wxWidgets, or the Fox toolkit can do what I need them to do. If Tk couldn't do it, there'd be no Iron Lute (or perhaps I would have dived into console-only, but that would not be fun). I've analysed each of them for what I need, even the very latest of QT and GTK, and they are all lacking in almost the exact same ways: I can't talk about formatted text in the widgets, I can't (usually) get the screen coordinates of the cursor, and there's no way to klude what I need.

(I need those things because I absolutely insist that when you press the "up" key on the top line of a given node, that you go to the bottom line of the next node up, and that you go to the roughly correct column in that widget... just like every other professional outliner I've ever seen. Anything less will not be usable. Without the ability to get the screen coordinates of the cursor, and set the cursor to other screen coordinates, this feature is impossible. And laying the nodes out on screen without being able to ask the toolkit "how big is this text" is really hard; I ended up re-implementing the Tk layout algorithm in Python, or at least something close to it, but if it changes or if I'm wrong, wierd and bad things happen on the screen. I'd rather not have to match it...)