Le Fri, May 17, 2002, à 01:09:11AM +0200, Mattam a écrit:
I wrote a plugin to allow transformations of the dia file using xslt. It is integrated as a plug-in that only do exporting. The user select a language in a separate widget when is chooses to use the code (*.code) file format. Only UML sources objects are supported yet as well as 3 export languages : C++, Java, IDL. I'm gonna refactorize it so that it can be extended.
Wow, it looks like you're going to make me orphan a package. I won't apply
it now, because we're frozen for an imminent 0.90 release (there will be an
RC2 in the middle of next week); however, viewed from outside (lacked time
to check the actual contents) this looks extremely cool, and it looks like
an inclusion candidate. Please do ping me about 10 days after 0.90 is out
(Pierre, your plug-in is also on the "inclusion candidates" list; please
ping me at the same time; this is why I've CC'd you explicitly).
Things to check for both plug-ins (where applicable) (may be done, not sure):
* GPL headers & copyright notices.
* what XSLT processor does it work with? (this'll need a patch to
the NEWS file)
* how does it behave when the XSLT processor isn't here? (we need to
have dia not depend on the xslt processor, just suggest it). Ideally, we
gray out the option; at the minimum, we should display an error dialog box.
* how does it behave when run from the freshly compiled, but not
installed tree (as in app/run_dia.sh) ?
* is the string handling UTF-8-clean ? This is a must. At the
moment, there still must be #hell to handle both a non-UTF-8 gtk (*nix) and
a modern GTK (Win32).
For the commiters: the attached archive contains the stylesheets, sources and a patch (diff with cvs) for the various Makefile's and configure changes. This plugin adds a dependency on libxslt. The plugin assumes that the stylesheets resides in $DIA_PLUGIN_PATH/xslt.
Oh, here's the answer to one question; you add a hard dependency on another
package. Is it possible/practical to make this a soft dependency (using the
dl_* functions)? That would make it possible to ship the plug-in in the main
package. Hmmm. If it's too much effort, don't bother; packagers will have to
make it a different binary package (from the same source). A little
inconvenient at first for the package maintainers, but neither unpossible or
that ugly.
ObPatchNote: it would be even better if the archive was only a patch (with
the new files patched against "empty" (there is an option for that in "cvs
diff")
-- Cyrille
--
Grumpf.
Attachment:
pgp1627RIWcyW.pgp
Description: PGP signature