On Friday, August 12, 2005, at 07:37 am, kr wrote:
Robert Strandh writes:
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
In terms of documentation I think deviations (which probably are _not_ gratuitous!) from the spec, fixes for vendor compatability and general documentation of extensions / extensions wanted would be useful.
what is the list of the current 5 top problems that would benefit from large architectural changes ?
Personally I'd like to see more structure in the organisation of the code (though this is quite superficial). I'd like to see a directory hierarchy for the code, many source files split apart (I hate long source files but maybe that's just me). I'd also like to see finer-grained packages (e.g. geometry functionality defined in :mcclim-geometry, drawing functionality in :mcclim-graphics, etc. etc.). These changes are pretty trivial.
I'd like to revisit the silica functionality; in particular, setting up transformations for sheets with a vertical dimension > 2^16 (which currently seems written specifically for CLX). I'd like some of the X restrictions removed from the code (I forget even where they are now, but I'm pretty sure there's code in the 'core' of McCLIM to restrict ellipses to rectilinear transforms only, for example).
I'm pretty sure there's a threading bug somewhere which doesn't show up under CLX due to (I think) the asynchronous nature of the X protocol (though this is perhaps more likely to be specific to Beagle - I need to do more investigation). Of course, if CLX isn't asynchronous I'm deluding myself...
I'd like to see a 'proper' test suite, just in case.
I'd like to see the menu code use CLIM menus (menu-choose-from-drawer etc.) which I don't think they do at the moment.
On the whole, I don't think many 'large architectural changes' are necessary. Most functionality seems to be present but there are corner cases that need to be investigated. Of course, more back ends might be good, along with extensions (going back to an earlier discussion regarding bezier path rendering, there's an implementation of this in the DUIM sources which looks like it would be quite straightforward to port into McCLIM). Output to PDF would be more useful to me than output to PostScript.
There's probably a bunch of performance improvements that could be made (spatial-tree based output records spring to mind).
I think generally the code just needs some polish and a LOT of documentation. Somebody maybe wants to pick up the QA task in earnest (I always planned to do this but don't really have time at the moment; anyway, Beagle is far from finished).
At the moment I'm looking at porting DUIM from Dylan to CL so if that goes anywhere there's likely to be opportunities for cross-pollination between McCLIM and DUIM (though how much overlap there will be in reality is not clear; probably not that much).
Just my tuppenny worth; all of which are on my todo-list, time permitting.
-Duncan
(i've only started listening in on this mailing list recently...)
-- regards markus krummenacker
mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel