2006-10-31

Getting annoyed again

Lately I've been rationalising and refactoring the code base of the large-ish XUL application which I've spent about half my work time this year prototyping.

Which naturally means I'm annoyed with JavaScript this week.


  • I really need a type checking JS lint. We're doing demos tomorrow, but after that I'll give JS Sorcerer a whirl. Last Friday I wrote my ToDo list, which currently has 117 items on it, my line manager is talking quite seriously about getting two or three extra staff to share my workload.

  • Managing packages and dependencies is a little clunky. This is true of all languages I've yet seen, and possibly Java is least worse (I've not done anything real in Common Lisp so don't know, though it seems neither better nor worse). I don't want to have to use a script to build the XUL files to ensure that everything is included; part of using XUL was to make it easily built.

  • I'm using the observer pattern a lot in the UI. This means virtually entity in the UI uses __defineSetter__ to map each of the object's properties to a structure containing the value and an observer list. I also am getting performance hits where multiple values are changed within a function, so observers are called repeatedly rather than firing them only one the values are all consistent. I really would like a language with transactions, concurrency and observers built in. (I must re-read the Fortress spec to see if it includes observers, or at least hooks on its equivalent of (setf (slot-value foo 'bar) baz) to allow them to be added).

  • There's nice JS syntax for initialising objects, and mechanisms for prototype inheritance, but there still seems to be repetition in creating constructors for objects with prototypes, lots of function Foo(a, b, c) { this.a = a; this.b = b; this.c = c; } Foo.prototype = new Bar();, where I'd like to get rid of all the this.'s. Maybe some type of prototype + merge/copy rather than classic prototype + constructor.

  • Probably my own fault for not using E4X, but creating SVG using the DOM is a pain.

  • Every now and again I still get bitten by XBL's asynchronous loading.



On the other hand, R. is back from paternity leave and so we now have subversion installed, so supporting the users who are using earlier branches should be less stressful.


TME

Labels: ,

2006-10-07

Better GUIs

Every now and then I go and have a look back at Java land. Yesterday I found this blog entry
John O'Conner's Blog: Better GUIs are one step closer.

It's very painful making good layouts in Java. For my last large Java UI project, which was based on porting a large mainframe ISPF application to run as a desktop application on PCs, I ended up implementing a layout and look-and-feel with most of the CSS box model on top of swing. I would have used XUL for it, but it was a Java shop and adding another platform was too political. There already is CSS look-and-feels in Java, so it shouldn't still be an issue getting things lined up right.

Anyway, I tried to do the same thing in XUL, so that it looks like this on a Mac:





source
css

Now, this took a little while while I remembered that you have to specify widths to ensure each flexible box ends up the same size, but the declarative syntax means you don't really need an IDE and a graphical editor, and the full CSS support means you can skin things if you like.

But that's not the real problem. Better guis are not just better aligned guis - they are concerned with user experience. And if you have to produce that amount of code just to align your fields, then you won't be agile enough to respond to your users.


TME

Labels: , , ,