LIC-Plugin
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| LIC-Plugin | Frank Lauterwald | 30 Apr 20:59 |
| LIC-Plugin | Sven Neumann | 03 May 22:58 |
| LIC-Plugin | Sven Neumann | 03 May 23:05 |
| LIC-Plugin | Frank Lauterwald | 05 May 10:25 |
| LIC-Plugin | Frank Lauterwald | 03 Jun 00:25 |
LIC-Plugin
Hi,
a couple of months ago I stated I had rewritten the old LIC(Van Gogh)-plugin. Sven suggested replacing the old version in CVS with the new one but I felt my version was too untested to do so.
At the moment I am neither aware of any bugs nor do I plan to implement any new features, so - unless there are severe objections - now might be the time to check it in.
Is there anything I have to do? Or will you maintainers have a look at it and do what must be done if it is accepted?
btw.: it still lacks automake support and stuff (meaning it has a normal makefile ...) , but the makefile is quite straightforward so anybody who is comfortable with automake (not me, sorry ) should be able to do the necessary changes within a few minutes
Frank
LIC-Plugin
Hi,
Frank Lauterwald writes:
a couple of months ago I stated I had rewritten the old LIC(Van Gogh)-plugin. Sven suggested replacing the old version in CVS with the new one but I felt my version was too untested to do so.
At the moment I am neither aware of any bugs nor do I plan to implement any new features, so - unless there are severe objections - now might be the time to check it in.
Is there anything I have to do? Or will you maintainers have a look at it and do what must be done if it is accepted?
I had a quick look and I have to say that I'm impressed. However to get the plug-in into the GIMP-1.3 tree, there are a couple of things that need to be done:
- 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.
- 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.
- Change the user interface so it fits better into the look and feel of GIMP plug-ins.
We can certainly help you a lot but I'd like you to stay the maintainer of the plug-in.
btw.: it still lacks automake support and stuff (meaning it has a normal makefile ...) , but the makefile is quite straightforward so anybody who is comfortable with automake (not me, sorry ) should be able to do the necessary changes within a few minutes
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. If you decide to maintain it separately, I'd suggest to look at the gimp-plugin-template on ftp.gimp.org. It should be easy to adapt it to your needs.
Salut, Sven
LIC-Plugin
Hi again,
I had a quick look and I have to say that I'm impressed. However to get the plug-in into the GIMP-1.3 tree, there are a couple of things that need to be done:
[...]
I forgot one more thing:
- 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.
Salut, Sven
LIC-Plugin
On Friday 03 May 2002 23:05, Sven Neumann wrote:
We should
however provide a backward-compatible PDB interface if possible.
IMHO this should not be necessary as the old LIC does not support non-interactive mode. And for interactive mode the PDB interface should be the same anyway.
- 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 I have the choice, I'd prefer CVS.
- Change the user interface so it fits better into the look and feel of GIMP plug-ins.
Any more concrete suggestions? As I am not an experienced GIMP-user (I simply do not work with graphics too much) I have not been able to see the "big standard" yet. Anyway, UI design is not the thing I am best at , so I could use a helping hand here. Not at the coding stuff but at the question "how should it look like?"
Ok, gonna fetch Gtk2 and GIMP1.3 and start porting now ...
Frank
LIC-Plugin
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
