Re: api break before release
You wrote on Fre, 25 Aug 2000: Date: Fri, 25 Aug 2000 01:08:42 +0200 From: Sven Neumann [EMAIL PROTECTED] [blurb about #ifdef GIMP_ENABLE_COMPAT_CRUFT] Are you sure? Why does it work for the gimp-print plug-in then? We've been using the old names. I ran Sven's conversion script to generate the new names, and put a whole stack of #define's in the one UI-related file that's shared between the 1.0 code and the 1.2 code. What about a common header that makes this defines? So a plug-in maintainer can use the new conventions and if the plug-in should be compiled for the old api, this can easily observed by including this header. (Don't know exactly about the under-the-hood complexity of what I'm talking about ;-)) Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: api break before release
Hi, Are you sure? Why does it work for the gimp-print plug-in then? We've been using the old names. I ran Sven's conversion script to generate the new names, and put a whole stack of #define's in the one UI-related file that's shared between the 1.0 code and the 1.2 code. It does make it harder to maintain the plugin for both releases, although not all that much so. I was referring to the version of gimp-print that is included in gimp CVS. It was left unchanged by me despite the inclusion of the line #define GIMP_ENABLE_COMPAT_CRUFT in print_gimp.h. This seemed to work very well. I'm happy however that you've decided to switch to the new API. Salut, Sven
Re: api break before release
On Fri, Aug 25, 2000 at 10:03:43AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: although not all that much so. I was referring to the version of gimp-print that is included in gimp CVS. It was left unchanged by me despite the inclusion of the line #define GIMP_ENABLE_COMPAT_CRUFT in print_gimp.h. This seemed to work very well. I'm happy however that you've decided to switch to the new API. Maybe it's just gimp-perl then. Maybe it's the fact that gimp-perl simply relies on all symbols, while gimp-print probably only relies on the most common (small) subset. In that case, most probably only gimp-perl is hurt... Which might also be the only plug-in where the community has considerable need to be convinced that a new version of some tool is as stable as the old one (because people's income depends on working servers) before they switch. Anyway, I *did* switch to the new API before writing my lament. I wrote that mail because I *do* think such an under-the-hood-change deep *within* the feature freeze is highly unconventional. So backwards compatibility is not just not my problem anymore. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: api break before release
Hi, Maybe it's just gimp-perl then. Maybe it's the fact that gimp-perl simply relies on all symbols, while gimp-print probably only relies on the most common (small) subset. In that case, most probably only gimp-perl is hurt... Which might also be the only plug-in where the community has considerable need to be convinced that a new version of some tool is as stable as the old one (because people's income depends on working servers) before they switch. Anyway, I *did* switch to the new API before writing my lament. I wrote that mail because I *do* think such an under-the-hood-change deep *within* the feature freeze is highly unconventional. Marc, believe me or not, but there was no great API change. The symbols gimp-perl used to use have been mapped to the new API until recently by defines and typedefs in gimpcompat.h and gimpenums.h. Now these defines are disabled by default and you can turn them back on with a small change to your Makefile. The number of symbols you use from that set should be totally irrelevant. Maybe your problems to get gimp-perl going with GIMP_ENABLE_COMPAT_CRUFT defined were related to the fact that gimp-perl seems to prefer to use installed libgimp header files over the current ones in the source tree. Salut, Sven
Re: api break before release
On Fri, Aug 25, 2000 at 06:02:30PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Maybe your problems to get gimp-perl going with GIMP_ENABLE_COMPAT_CRUFT defined were related to the fact that gimp-perl seems to prefer to use installed libgimp header files over the current ones in the source tree. There is no evidence that this is the case. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: api break before release
Hi, While, in theory, I agree that having compatibility cruft inside a software package is bad, I think breaking compatibility deep within a feature freeze was a very bad idea. I thought different this afternoon when I could just enable GIMP_COMPAT_CRUFT_STH, but it just turned out that this define only catches very few of the API changes. There were no API changes at all. All of the names that are standard now have been around for a long time and the only thing we did was to reverse the logic of the COMPAT_CRUFT defines. What was #ifndef GIMP_DISABLE_COMPAT_CRUFT before, has become #ifdef GIMP_ENABLE_COMPAT_CRUFT now. That's it! Nothing else changed!! So, in effect, the recent undiscussed changes completely break the API and make it impossible to maintain a plug-in for both 1.0 and 1.2 versions. Are you sure? Why does it work for the gimp-print plug-in then? Salut, Sven
Re: api break before release
Date: Fri, 25 Aug 2000 01:08:42 +0200 From: Sven Neumann [EMAIL PROTECTED] There were no API changes at all. All of the names that are standard now have been around for a long time and the only thing we did was to reverse the logic of the COMPAT_CRUFT defines. What was #ifndef GIMP_DISABLE_COMPAT_CRUFT before, has become #ifdef GIMP_ENABLE_COMPAT_CRUFT now. That's it! Nothing else changed!! So, in effect, the recent undiscussed changes completely break the API and make it impossible to maintain a plug-in for both 1.0 and 1.2 versions. Are you sure? Why does it work for the gimp-print plug-in then? We've been using the old names. I ran Sven's conversion script to generate the new names, and put a whole stack of #define's in the one UI-related file that's shared between the 1.0 code and the 1.2 code. It does make it harder to maintain the plugin for both releases, although not all that much so. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
