Daniel Rogers <[EMAIL PROTECTED]> writes:

> Sven, I think what he was saying (and please speak up if I
> misinterpreted your english) that he would like to become the
> current maintainer of the current tiff plugin.

That is something the current maintainer of the plug-in has to decide.

> I certainly see no reason why this person can't have responsibility
> over the current plugin as long as he doesn't revert the
> improvements made to the gimp-2.0 plugin.

I am certainly not trying to discourage anyone from taking

> Also, the best way of gettting rid of the #if's would be to put some
> app specific functionality into a seperate file and compile or
> include only one driver file for the tiffreader plugin.  I am all
> for this.  I suspect, though you haven't said, that you are also
> working on the CinePaint plug-in.  It would be good to share as much
> code as possible between our projects, IMO.

Since both projects build on a different framework this attempt is IMO
doomed to fail. Especially since judging from the project's roadmaps
the two frameworks will continue to diverge in the future.

I really don't want to see this code replace the current tiff plug-in
because I believe it will be a maintaince nightmare. When I grep the
plug-in sources, I don't want to get hits from codepaths that aren't
used by the GIMP version. When I review diffs I don't want to have to
care about changes that aren't in our code.

If we would attempt to do this, it would be as if we would decide to
keep plug-ins for gimp-1.3 and gimp-1.2 in the same branch in CVS. We
could add #ifdef's for the parts where the APIs differ and so we
wouldn't have to merge bug-fixes between the branches. Why aren't we
doing this?  Because it would be a nightmare to maintain. It's a lot
easier to merge a change done in the HEAD branch to the gimp-1-2
branch and vice versa than it would be if you had to make sure you are
doing the same fix in two branches of a preprocessor directive.

Anyone who would want to seriously work on this code would have to be
able to compile the plug-in for all supported applications. This would
put an insanely high burden on anyone willing to work on this plug-in.

> At worse, you can put it all in the same file and #if away the block
> of fuctions specific to a certain app, which is _MUCH_ more readable
> then having #ifs in the middle of the code.

What you will end up with if go that way is basically what I suggest
to have: One tiff.c file for The GIMP, a different tiff.c for
CinePaint. IMO it will be easier to merge changes between two or more
versions of the plug-in than to attempt to maintain one plug-in for
two or more applications.

Please don't get me wrong. I am not trying to discourage anyone. On
the contrary, I would welcome to see the projects share code and
Kai-Uwe surely did some improvements to the tiff plug-in that we want
to see in GIMP CVS more sooner than later. However I dislike the
proposed way of doing this.  IMO we should merge the improvements one
by one. Later bug-fixes can be merged between the two projects based
on patches. This will IMO be a lot more convenient.

Gimp-developer mailing list

Reply via email to