[mcclim-devel] One char patch to presentation-defs [really future of McCLIM]

[Duncan Rose]

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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>