dinasset wrote:
I think that either the API should provide the same parameters as the online or -at least!- the default behaviour should be the same (online it creates a selection, via API it does not when called after a "selection all").
You have certainly noticed that in my scrtipt I was obliged NOT to use the same command used online, but to replace it with the "shrink + invert" sequence of statements.
Don't you think that a "fix" of the API could be requested?
In general it is not necessary for the PDB API to match the interface dialogs. There are several instances where the user interface offers options not directly accessible in the PDB API.
Sometimes the "inconsistency" is caused by the nature of the option being interactive. For example, "Show preview" doesn't affect what the filter does, only what is shown in the dialog. There are also interface elements that are conveniences provided for the user. For example, the "x/2, y/2" options in the layer offset dialog. Or the "Lock thresholds" option in the Color Exchange filter. Such options have an effect on what the filter does, but are easily accomplished by simple calculations of the relevant existing parameters. If these options were available in the API, the API would have more arguments, be more complicated, and need to handle more error conditions.
Once one accepts that excluding such "convenience" options from the API is sensible, it is not that much of step to consider how prudent it is to simplify the API by restricting options that are easily accomplished as a separate operation within the plug-in. For example, the Add Layer Mask dialog has an "Invert Mask" option while 'gimp-layer-create-mask' does not -- yet it would be trivial for a plug-in to achieve the same result by performing a 'gimp-invert' after creating the mask. Similarly for the selection border operation, it is pretty trivial for a script to perform a 'gimp-threshold' on the selection after the bordering has been performed to obtain the same result as unchecking the "Feather border" box in the dialog.
Equally important as keeping the API simple is the issue of backwards compatibility. Modifying the API of a PDB function necessitates revising all existing scripts/plug-ins that used that interface so they will work with the updated API. This is far from desirable and there is a firm policy* against it. It is acceptable to add a new PDB procedure that uses the revised API (e.g., gimp-layer-scale-full, gimp-drawable-mask-intersect) but then the original procedure is still retained, with the same name and arguments, so that existing scripts/plug-ins will continue to behave properly.
Note that there is no policy against modifying a plug-in's dialog interface, only its PDB API. While drastic changes in the user interface are typically discouraged, users can readily adapt to new or changed options. Over the years it has not been uncommon for dialogs to be enhanced with additional options ("center", "monochrome", "keep luminance",
"feather border", etc). These enhancements did not affect the PDB API of existing functions and new functions were rarely deemed necessary.
From a scripting standpoint, there is no actual reason to even have a border selection PDB procedure as the operation can be readily accomplished with just a few existing functions (selection grow/shrink, combine masks, etc). The
only reason to have the procedure in the PDB is to support the menu command. Given this, it is highly unlikely that a new procedure would be accepted just so that its API matches the user interface dialog.
* GNU policy is that API changes will remain backwards compatible within a major version. If it were deemed that the API should change in an incompatible manner, such a change could only be implemented when GIMP 3.0 comes out -- GIMP 2.10 is expected to run all previously written 2.x plug-ins (otherwise it is considered a bug). Unfortunately, the GIMP project has not been in 100% compliance with this policy.
Login
Register
Tweets
FAQ
Advanced Search
