Industry musings

Well, it's been a while. I'm still working on DUIM, on and off. I'm going through an 'on' period at the moment, for better or worse :-)

I've 'fixed' some of the issues I was having with the code; in particular I've implemented a work-around for the Dylan methods that specialise on subclass(<class>) using metaclasses. Basically each class defined via define-dylan-class also gets its own metaclass defined (so the metaclass hierarchy mirrors the 'concrete' class hierarchy).

I don't like this approach :-)

In the gadget-text-parser and gadget-value-printer methods I've made use of class-prototype objects instead which is a slight improvement.

I think the best solution will be to work out how to create new CLOS specializer classes; implementations provide EQL specializers and I guess it should be possible to implement a SUBCLASS specializer. I'll have to look into this.

The code is still confused regarding the use of lists and vectors, but on the whole the codebase at least hangs together in this regard. This needs revisiting at some point in the future. It might be nice to implement (or find, it's possible something exists already) a generic CLOS-based collections package (I can see the value of operating on lists / arrays via different methods, for efficiency reasons -- but I really like the Dylan approach that wraps all collection types up in a single API).

I've stopped working on any back-end code at the moment. My priority is in getting the fun-O tests to run (not necessarily pass!). At the moment around 2k of them run, and about 85% pass so I'm nearly there with this, I think. It does seem that some of the tests target a different version of DUIM than the code I have though; the most obvious case of this is in the tests for text-styles, which don't pass a name to the methods. All the text-style code in DUIM appears to require a name (as well as a family). The documentation I've seen supports the tests, but the documentation might be out of date. There are other examples too (<TEST-STATUS-BAR-PANE> inherits from <LEAF-PANE> but the status-bar handling methods want to (setf (sheet-children bar) ...); this works in DUIM since DUIM's status bar inherits from <ROW-LAYOUT> which includes <MULTIPLE-CHILD-MIXIN> -- but if the DUIM code was always organised the way it is at the moment, the status bar tests can never have worked.

I guess I'll get there in the end.

My plan of attack at the moment is:

• Get the fun-o tests running, and fix any low-hanging fruit to get as many passing as possible. At this point, DUIM-CORE, DUIM-TESTS and DUIM-EXTENDED will be completely ported, barring errors (I don't think there are tests for the extensions for example)


• Write a back-end. I'll probably port the existing win32 back end since at the moment that's the platform on which I'm doing most development on this. I want to see something happening on-screen now...


• Port the examples and demos -- and write a couple more


• Port DEUCE

I think there may be some light appearing at the end of the tunnel :-)