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?

Chandler 0.6 is out

Chandler seems to have been coming along fairly slowly for a while. I’m not sure how exciting this is but could be the beginning of something interesting.

The Chandler team have been building up some Python infrastructure, grappled with various technologies, and rejected the ones which have turned out to be too much trouble to work with.

Maybe they have some nice components?

Now they’ve done a sensible thing and focused on one application : shared calendaring, which they hope will get them some users and attention (the most useful resources). After that, they can expand to other applications.

OTOH, calendaring doesn’t interest me much.

Structured blogging–what’s in it for users?

Well, trying to make ordinary users add more structure to a blog entry is a non-starter. The way to go is to find people who are already entering structured data, and allow them to do it to their blogs.

The clue here is spreadsheets. Dan Bricklin is on the right track with WikiCalc, although the UI isn’t right. But what about a plug-in that lets you post to a blog directly from Excel?

Today, a comment I left on Don Park’s blog got quoted by David Berlind.

Here’s what I said :

Here’s the amazing thing : there are about 8 billion pages accessable through the browser. And not one of them is that difficult to get to. (Assuming you find links going there.)….How many OSs and desktop applications have 8 billion options and functions? Yet, access to these is through a bewildering variety of different methods : menus and submenus, button-bars, wizards, right-click on the icon to change configuration options, hidden XML configuration files, command line arguments.

But then David says something very right :

Given the way wikis make child’s play out of Web authoring (and the emergence of applications like WikiCalc), instead of a desktop operating system, how about a Wiki Operating System. Call it WikiOS (WOS for short).

This is, of course, something I’ve thought for a long time. And it’s one of the guiding principles behind SdiDesk, hinted at several times in the screencasts.