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.
>  - 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 
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 for you.
thanks a lot; in the meantime I have been able to write a myself. 
But there's surely room for improvement ...
For compiling the plug-in separately, however, a normal Makefile is still 

Ok, so everything should be done except a better user interface.
I appreciate any suggestions about how I should change it.



Gimp-developer mailing list

Reply via email to