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
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
