On Fri, Dec 19, 2003 at 11:03:52AM +0000, Tom Payne wrote: > The module is provided as a patch because only the font and colour > handling code has changed, less than 6% of the total, and it would be > ridiculous to duplicate the brush handling, configuration, border > drawing, etc. etc. of the de engine.
To avoid name conflicts, everything de_, debrush_, etc. should be renamed in the resulting module. The de_ stuff in the configuration files and delib needs to be changed as well. I would think that the best way to maintain such a module would be to use CVS (or whatever version management system) branches. Import the original module, tag it, make your changes. When there are changes to the original module that are worth merging, just checkout the older release (the tag), copy over the new files, commit, create another new tag, and, update -A to merge with your changes. (IIRC, but google cvsbook.) Alternatively the original module could be made an awful mess, allowing renaming functions, and you would just #define something and compile with the original sources and few files replaced. But the CVS solution sounds better to me. Of course one could add extra kludges to effectively support font modules as well, (and I've actually been considering simply using pango in a (far) future development version, although it is g-overengineered, bloated, and currently bug-ridden), but I really prefer a keep-it-simple-stupid approach, almost everywhere, even if it means a little extra work. > I think this is because > the dock module assumes the presence of a drawing engine module, but the > xftde module is unloaded before the dock module, meaning that during the > dock's deinit routine there is no drawing engine module. Modules are not unloaded until all screen objects have been destroyed. -- Tuomo
