Kicking a dead horse

This is my first week of my 8 months of daddy-duty. I've got a bit more free time now, not an obscene amount more, but Eowyn is very easy to take care of and she sleeps quite a few times during the day so I've found myself spending more time thinking about my after-work projects.

So, as I was converting the ClipsJNI demos to wxPython/pyClips (still one to go though) I realised that I might have use for a project I worked on a couple of years ago.

The summer of 2004 I wrote an "application browser" based on wxPython. The easiest way to explain what it does is to think of it as a regular web browser but instead of reading HTML and generating a view it reads something I called wxWML or wxWidgets Markup Language (wxML was taken already) and "generates" a wxPython rich client application.

The project is called wxBrowser and can be found on SourceForge. We used it at work to deploy an application we couldn't get working in the web browsers at that time. Today, there are several options that are much, much better of course. XUL and Eclipse RCF come to mind.

Anyway, I made one last release in the summer of 2005 and I haven't looked at it since. Until today that is.

It turns out that creating a GUI for a Clips application requires you to divide your application into (at least) two distinct parts that are quite tightly coupled. You can try to make the coupling looser by having a more dynamic GUI application that decides what to show on the screen based on Facts in Working Memory (see the Auto Demo for an example of this). But there will still be quite a lot of GUI specific code that won't be all that dynamic. Which, as it turns out, was exactly the problem I wrote the wxBrowser for in the first place.

If I can translate Facts in Clips' Working Memory to wxWML I could use the wxBrowser to provide a GUI for a Clips program. Sure, I'd have to write a whole lot of rules and functions to get it to work but at least I won't have to do it in another language or environment. The wxBrowser itself can be distributed as an .exe which contains pyClips so all you really need is the Clips program to run and you're good to go.

There's of course a down side to all of this which is why I decided to go with the Kicking a dead horse title instead of Blowing new life into old things or something similar. First of all, wxPython code (and the structure of the library) isn't always that easy to understand. This was one of the major stumbling blocks in 2004 and it hasn't gone away. Secondly, there's a reason people use all sorts of tools to generate GUIs and last time I checked there was no tool that could save in Clips' deffacts format. Third, it's an evil bitch-monster of death to debug if something isn't working as expected (which almost ALWAYS is the case when working with GUIs).

Well, luckily I've gotten quite good at kicking dead horses over the years so I'll give this idea a try in the next few weeks. If it doesn't work out, I'll just bring it up again in 2012 or so ;-)

[2008-01-10] Update: Fourth, Client-side scripting. This will actually be less of a problem with Clips as a backend because, well, there wouldn't be any need for client side scripting since the back end is available all the time unlike in an HTTP environment.