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
Script-fu: Burn-In V1.9 is out
First, let me say thanks to all people who gave me feedback and sent me bug reports the last days. This helps alot (and keeps me on working ;-) Now for the news: I've just released Script-Fu "Burn-In" V1.9 for Gimp 1.0.X. You can now use your own background-layer and create fascinating text animations for the web. Please note that this version is considered as pre2.0 and therefore still "beta". It works, but I didn't have the time to do extensive testing. :-/ (Burn-In V1.0 was already announced by Xach some days ago (thanks!) For download demos please see http://fuchur.leute.server.de/burn_in/ Roland
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 | |
