Hi! On Sun, Feb 7, 2021 at 5:59 PM Lloyd Konneker via gimp-developer-list < gimp-developer-list@xxxxxxxxx> wrote: > The v3 PDB API has changes for multilayer capability. > For example this signature change: gimp-edit-copy(drawable) => > gimp-edit-copy(drawableArray). > This breaks some scripts in the GIMP repository and some third party > plugins. > > To provide backward compatibility means allow existing scripts to work for > a defined period. > (say from 2.99 until 3.1). > Just for the record, there are no such versions: 2.99 and 3.1. Or to be accurate, these are dev versions, they don't "count". Whatever is in 2.99 and whatever will be in 3.1 doesn't matter but for testing. We don't mind too much broken stuff in these (we obviously prefer non-broken stuff, but this won't stop us from releasing something for people to test the rest, i.e. what is not broken). As for API in particular, it means that API compatibility is a non-existent concept there. We are heavily testing. The API may end up broken even between 2 micro releases (like 2.99.4 to 2.99.6). This is what these versions are for. What matters is only that we get the right API for GIMP 3.0. That allows users time to adjust their scripts. > It had been decided long ago that the API could break for our GIMP 3.0 release. I mean, the multi-layer related functions you give are only the tip of the iceberg. There are so many more changed functions, and in particular all the base API for plug-ins are changed anyway. Now the old base API don't even exist anymore. So anyway all plug-ins will have to be updated. It's not even an "if" anymore, and it's not even related to multi-layer selection (even without this, all plug-ins will have to be updated). I mean, it's already too late. We have not just started or anything. This work on base API changes started more than 2 years ago (after we released GIMP 2.10.0) and reverting this (losing 2+ years of work by several people and using probably just as much to bring compatibility back) is not an option as far as I'm concerned! > If we don't provide backward compatibility, it is a logistics problem: > third party script authors must prepare an updated copy of their scripts, > and change over immediately when they change from 2.10 to 3.0. > Which is also why we have started to talk about this long before, made news about this on GIMP website and we started to release dev versions. The current dev API is unstable (as already said), but it's still close to what will be released as stable. So plug-in developers are very welcome to start porting. Whatever will change between now and finale stable GIMP 3.0 likely won't be as much as what already changed between 2.10 and current dev version. We also plan to document the main changes, with porting docs, tutorial and whatnot. And also we hope to have the new extension platform by the time we release GIMP 3, to help people port their plug-ins and upload them. In the end, the change won't be so complicated. It may look scary, but in the end, I don't think even the most complicated plug-ins will need much more than 30 min to be ported. Ok maybe 1hour if reeeeaaaally you made a hugely complicated plug-in, I don't know. Talking from experience of having participated to port many of our core plug-ins. > Some scripts in GIMP 2.99 are broken now since the API was changed but > scripts were not updated. > If we provide backward compatibility, > the GIMP developers can fix the scripts in the repository at their leisure. > Are you talking about third-party scripts or the ones we provide? If the core ones, of course we should port them before release. But not providing a compatibility layer again. As said, GIMP 3 is our chance to improve our API, 25 years of cruft, 25 years of evolution, new features, new usages, so many things different. The goal is not to continue with double the mess. Like if we talk about multi-layer related API, what? Do we want to propose every layer API in double now? Both multi and single layer? Then do the same when we finally make vectors and channels multi-selectable? I'm not saying what you say is wrong. Of course, in an ideal setup, we try to never break any past API. But in this ideal setup, we are more than a handful of contributors. Right now, trying to do what you propose would be like releasing GIMP 3.0 in 5 years. I don't think anyone wants this. So yeah this is why we just decided long ago that API breakage was allowed as it was a major version update. We don't do useless API breakage, but for stuff like multi-layer selection, this just makes sense. It will be a new ability of GIMP 3. Nobody wants our API not to be able to access this feature. And we don't want to maintain double the functions. > Because the name has stayed the same but the signature changed, > to provide backward compatibility could be considered > a problem of overloaded functions. > > One backward compatible solution is to implement overloading in scriptfu: > whenever calling a PDB procedure, examine the actual arguments: > if an arg is a single drawable, convert to a drawable array. > (You could also do the same in GimpFu v3, if any.) > This feels like it would be a bug nest. > An easier solution is to revert the signature change. > Instead add a new PDB procedure gimp-edit-copy-multiple(drawableArray). > Also redefine the body of gimp-edit-copy(drawable) > to convert to an array and call the core function taking drawableArray. > Of course, what you propose is possible. Maybe we could just do this anyway. I'll think about it. > In other words, the old gimp-edit-copy(drawable) becomes a 'convenience' > procedure > for the more generic gimp-edit-copy-multiple(drawableArray.) > You could also think of it as a "compatibility" procedure and warn that it > is deprecated. > A whole point of starting fresh with v3 API is not to start with deprecated API. We will have the time to get new deprecated API (in possibly the next 25 years? 🤣). Should we really start directly with some?! > Then if you don't want the PDB full of convenience/compatibility > procedures, > you could obsolete the procedure later (at say v3.1). > Again v3.1 won't exist (it will, but not really 😛). You mean 3.2. > You could also argue that the original meaning of gimp-edit-copy is more > natural. > Few script authors are even thinking about multiple layers. > Because the concept didn't exist back then. Nobody was thinking about multiple layers composited together (except for the full image). Now this will exist in the GUI, so the API should have the concept too. > Relation to issues on ScriptFu: > This is issue #6026. > Some other backward compatiblity issues are dealt with by MR 403, but not > this one. > A fix to scriptfu for #5402 is also necessary, but is not 'for backward > compatibililty.' > > Some have suggested that ScriptFu could use GObject Introspection (using > say Guile-GI) > in which case all scripts would need to be rewritten to use GI > at least to deal with the broken PDB calls. > Some hard-core lisp programmer would also need to step forward > to integrate Guile-GI (or some other) with ScriptFu. > Yes it was just an idea because from what I see, script-fu scripts are seriously limited (PDB only basically). It would be nice if they had access to the full libgimp* API (like Python and other languages have now). Now that's just an idea I'm throwing. I don't think I'll want to spend too much time on this and would love for someone else who actually cares about GIMP's historical lisp support to step forward. Jehan _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- ZeMarmot open animation film http://film.zemarmot.net Liberapay: https://liberapay.com/ZeMarmot/ Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
