Hello, Am 28.11.03, 01:07 +0100 schrieb Sven Neumann: > Daniel Rogers <daniel@xxxxxxxxxxxxxxxxx> 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 would be interessted in the current maintainers opinion related to this plug-in. > > 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 Sounds good to me. This is something I would do to make the gimp specific parts easier to understand in one common plug-in. > > 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. Robin Rowe installed an compatibility layer so nearly all gimp-1.2 plug-ins can compile. I think this is an essential step to make the distance of both applications smaller not greater. As long as we talk about plug-ins, why not use the common interface in both directions? For instance, to enable CinePaint support for the orientation tag in tiff, I am willing to add the missed flip PDB entry. I see there no problem. > 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. At the moment my tiff version could be more clear and it is hard to understand for others. So I offer to follow Daniels suggestions and separate GIMP and CinePaint things as described by him. So an differenciated working in both apps would become likely. I did only a first step toward supporting GIMP. > 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. It is up to the responsible maintainer, IMHO, to make changes compile in an specific application. I can imagine that something changed in the GIMP specific part will need some overwork by me for CinePaint or filmgimp (as long as I need the old gui). > > 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. I work now over one year on this plug-in. The point for me is they diverged as I needed to fix things and added new capabilities. Many variable names changed. So it is harder to jump from one plug-in to the other. I did the big change with the CinePaint plug-in in order to adapt Nick Lamb s big overhaul. It took me much time after the merge to get the thing working again. Now there are many new things coming from my side. Equal who does this work GIMPs maintainer or I, this will be much wasted time. What I offer is to set up the base of an potential, maintainable, mostly common plug-in, with further need by me to make things more clear. > 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. I expect You try to avoid trouble coming from bugs which get introduced by a completely new plug-in. While adapting, You get a new plug-in either, which needs much debugging too. Otherwise You could erase all CinePaint specific parts and test and life with a new plug-in. This is not the badest thing. Missed or lost features may be reworked together with the GIMP maintainer. This would really help of course. The measure of my work is an test suite which needs to be solved. This is the most relyable thing I have. (Further unsolved test tiffs are welcome.) regards Kai-Uwe
