done some homework Sven gave me (on the new LIC-plug-in) ... On Friday 03 May 2002 22:58 Sven Neumann wrote: > - Decide if you want the plug-in to be kept and maintained in GIMP CVS. > In the beginning you'd send patches but I think we could get you CVS > commit access pretty soon. if it gets that far, I'd prefer CVS as I am more used to CVS than to the patching business (yes, basically that's easy but nevertheless ...) > > - Port it to GTK+-2.0 and GIMP-1.3. This task should be pretty > straight-forward. done > > - Change the code to be compliant to the GIMP coding style. A good start > would be to use indent with default settings (GNU coding style). The > GIMP coding style is described in the file HACKING in the GIMP source. > Not all plug-ins comply to it but we don't want to accept new code > that doesn't. done - (though I probably missed a few things) > > - Change the user interface so it fits better into the look and feel of > GIMP plug-ins. here I asked for guidance a while ago, as I am absolutely no UI guru. If someone tells me how it should look like, I will change it. As for I18N and removing deprecated widgets and stuff: I'd like to do this as soon as the UI is stable. > > - We need to decide if we want the plug-in to replace the old LIC > plug-in or if we want to keep the old one around. If the results are > similar enough I'd vote for replacing the old one since exposing > more choices to the user is not always the best solution. We should > however provide a backward-compatible PDB interface if possible. We > can then add a plug-in-lic2 PDB interface that exposes all the new > features. well - here comes the funny part. The old plug-in has a serious overflow bug (for those wanting to know exactly: plug-ins/common/lic.c around Line 785: themap[index++] = (guchar) (val) * 255.0; themap consists of guchars, val is [0..255] -> guchar*255 normally is no valid guchar. The multiplication with 255 is simply wrong here) I do not understand how this could remain unnoticed for 5 years as this bug makes it completely impossible to obtain results similar to those on Tom's homepage. In other words: The old plug-in has been completely broken for (as it seems) several years. Note: broken means "unable to do what it should", not "unable to do something cool" Conclusion: Anyone who has used the old plug-in has not used it for what it was supposed to do, but for something else. I wrote a "backward compatibility" mode (which basically emulates that bug) which produces almost exactly the same results as the old plug-in. ==> similar results can easily be achived if wanted As for the PDB interface: the old plug-in had just one entry (run_mode/image/drawable). The new one provides this too, of course. > We can certainly help you a lot but I'd like you to stay the > maintainer of the plug-in. > ... > if it gets integrated into the gimp source tree, you don't need to > worry about automake and autoconf. I'll write the Makefile.am for you. thanks a lot; in the meantime I have been able to write a Makefile.am myself. But there's surely room for improvement ... For compiling the plug-in separately, however, a normal Makefile is still included. Ok, so everything should be done except a better user interface. I appreciate any suggestions about how I should change it. Cheers Frank www.uni-erlangen.de/~sifrlaut
