OK, some more thinking out-loud about possible futures for SdiDesk in light of that TurboGears demo.

Nothing is fixed. Particularly not SdiDesk. This is all speculative.

What is SdiDesk? Idea? A prototype? A useful tool? A code-base? A finger-post pointing out the direction I'd like to see individualistic knowledge tools evolve?

All of the above. Of course.

SdiDesk is the future. :-)

But there's also no doubt in my mind that the code-base (or rather, the language VB) is a major strategic problem.

I won't say "error", because it's very unlikely I'd have written the program at all without the support of the VB environment and easily accessible components like the IE DHTML control.

But it's a major problem because VB classic is a dead language :

• a) No one is actively supporting it, or developing free components. It's more dead than Lisp and Smalltalk who have enthusiastic free developer communities. VB's main virtue is its symbiosis with MS, and now MS have dumped it (I mean VB classic), there isn't even that.


• b) Nobody wants to write it or become involved in the code-base. Not even me.
  
  The code-base could be evolved towards either RealBasic or VB.NET. And if I had a strong incentive, I could take it in one of these directions (OK, if somebody offered me money :-) But I feel no personal urge to get involved in these languages.

I want to write in Python. (Or maybe Ruby or Smalltalk.)

I guess if somebody else wanted to drive it, I'd support, and help out with, a port to Java too. (At least there'd be some potential future.)

Over the last few months I've been dabbling in Python for some smaller projects and I've seen quite a lot of how a Python port of SdiDesk could go. I even have a strategy to start implementing "exporters" in Python and some rudimentary code for that.

But the big issue is that I'm happy with none of the GUI libraries. My new program (which is coming out real soon) uses Python and Tkinter. It's alright. It's easy and it works. But the results are not going to win any beauty contests. It's uglier than SdiDesk (although you chromophobes might find that hard to imagine. :-)

wxPython looks better but needs installation of third-party libraries; as do GTK, Qt etc. And I don't want to be dependent on Windows.

And then there's AJAX.

A few weeks ago I was speculating on another blog about Python, Gecko and XUL.

But, in fact, there's something simpler. Watching the TurboGears demo (and just how bloody simple it is to put together basic wiki functionality in TG - something which takes plenty more lines of code in SdiDesk's current VB implementation) I'm starting to wonder whether a browser based UI might not be as good as any other.

Python has an easy-to-use web-server component in the standard library. To someone using the program, a server at the heart would be transparent. But it would allow you to create shared wikis with others on your LAN or even over the web.

At the same time, AJAX component libraries are starting to get pretty sophisticated. Look at Rico and Dojo.

The only thing SdiDesk can do that a standard browser can't is the network diagrams. And on Firefox, with its canvas and SVG tags, even that might become possible.

Of course, TurboGears needs a database, and I don't want to get away from the current file-system.

But, forgetting TG, I am starting to wonder whether browser-based UI technology has basically caught up to pretty much the standard of any interface I could implement with Tkinter or similar GUI toolkit; and whether it wouldn't be just as useful for SdiDesk users to go via the browser.

Any thoughts?