You are here

Home › Forums › Plugins & Scripts

Script Management

July 7, 2009 - 22:48 — ffaat

First off I want to thank the site management for creating a place to host scripts and plugins. The loss of the old registry with no replacement would have been a tragic loss to the entire community of Gimp users.

But... I feel there are a few problems with both this site, and the way that scripts (and plugins to a lesser degree, as there, in general fewer of them) are "managed" (or more specifically, not managed!)....

Here are some of the issues with scripts that have been uploaded here:
- Scripts uploaded that duplicate the functionality (in whole or part) of already existing scripts.
- Scripts that have non-descriptive names and/or descriptions.
- Scripts that register themselves in "curious" menu locations.
- Scripts that are so trivial that it is surprising they were even written in the first place.
- Scripts (most of them) that provide no internationalization (can they even do that?)

Would it be valuable to potential end-users if there were some rules around scripts being uploaded here?
Could they be enforced?

I know that for the core gimp code, changes are deliberated and introduced by core developers based on decisions made on Gimp's software vision. It almost seems that having a big, disorganized pile of scripts defeats that a bit. I know that a number of scripts are bundled with gimp, and their location and attributes are managed. Should that be the case for scripts here?

I've written scripts, and had a hard time knowing where they should be registered in the menus. Sometimes what I think is obvious turns out not to be! It would be nice if there were guidelines on where things should fall in the menus. many scripts still end up under "script-fu" because they are legacy scripts. I would be nice if these were changed to more reasonable locations.

Would providing some sort of hierarchical/category listing of plugins work better than the existing current keyword index and script names here in the registry?

Initially I though that some of these things would be the purpose of the gimp-plugin mailing list, but it seems dead. I've asked a couple times on the gimp-devel list but they seem more focused on the application than third party scripts.

In my mind, I imagine a "GPR Approved" type of evaluation on a script saying it doesn't have any issues...so people could still be free to write what ever they want (it is a free world). I know that http://gimpfx-foundry.sourceforge.net/ does this (I think) to a degree, but to be honest, I don't know their relationship to this site...

I just wanted to throw out some ideas/start some discussions on this.

-Rob A>

Forums: 
Plugins & Scripts
July 9, 2009 - 14:36 — bootchk

One approach is a convention that every plug-in separate its engine from its GUI. In other words, every plugin is two parts (scripts or C executuable): an engine part that doesn't register a menu item, and a menu part that registers a menu item and does nothing but call the engine. (Note that the engine MIGHT still provide GUI in the form of dialog boxes, but doesn't provide a menu item. But I think THREE things should be separate script files: engine, dialog boxes, and menu item.) If developers adhere to that convention, then another "plugin master" script could shuffle menu items around by unregistering menu parts and reregistering them into menu structures that follow standards or conventions suggested in this thread. But the plugin master would need a database of all plugins known in the universe and a map to the consensus best menu structure for those plugins. Its a social problem: getting developers to follow conventions and a power struggle over the best plugin master, the best menu structure. See the gimp API reference for Initialization & Plug-In Management: http://developer.gimp.org/api/2.0/app/app-plug-in-management.html I don't see a way to delete a menu item for a plugin, or a way to register a plugin except under the menu item specified inside it. If you could, then maybe one could write a "plugin master" script that rearranged the menus without requiring separation of engines from menu items. In other words, maybe one could write an alternative "Reload scripts" script that ignored loaded script's own menu specs when better menu specs are known. Is that what is needed, a change to the GIMP API to allow a "plugin master" plugin? (Maybe that capability is already in the API and I don't see it.) (Yes, someone might write malicious plugin masters.) See also my thread in this site under "plugin architecture". No doubt this topic has been covered before. Any existentialists want to comment on the absurdity? If a plugin has only registered its menu item once, has it really happened? plashless, off banks of noon
July 9, 2009 - 20:10 — schumaml

Separating procedures from menu locations

The menus of GIMP are - at least to some extent - described by XML files. It would be worthwhile to check if something like the following can be implemented without too much effort:

Plug-ins and script try to register their procedures

  • a unique placeholder
  • a top-level menu
  • and a fallback menu location
If this unique placeholder is found in the menu description file corresponding to the top-level menu, the entry is placed there. Otherwise the fallback location is used.

If this unique placeholder is found in the menu description file corresponding to the top-level menu, the entry is placed there. Otherwise the fallback location is used.

GIMP could be changed to require this unique placeholder, otherwise the plug-in or script won't be loaded.

Separating procedures from their UI

This would require to get more developers to use GTkBuilder in their plug-ins (not in Scheme scripts, though).

July 11, 2009 - 17:43 — ingo

Rob, I share your sentiment ;-) A number of quality criteria for scripts would certainly be useful, not just for end users but also for the developers themselves, as guidance. I am thinking of something like a "style guide". Start with a few unambiguous rules and then expand. Regarding the role of the registry, adherence to guidelines cannot be automatically checked, so such things would require more people to become involved. I would prefer an after-upload check, here. As far as I can tell, there are already some people active on the registry (e.g. PhotoComiX and schumaml come to mind) who are looking at new content, providing guidance and helpful comments to uploaders. This seems to be well received. Maybe these two could comment on their view, but to me, this model seems workable. The existence of guidelines could help in this regard, to provide a common point of reference, with justifications, thus reducing the amount of explanation needed for new cases. Additionally, some form of overview pages could be created, to ease the task of inspecting larger amounts of content at once. In Drupal lingo, this is called "views" and I can assign the ability to create views to anyone who wishes to participate. Let me know if there is interest! Cheers, Ingo
July 12, 2009 - 23:50 — PhotoComiX

Quote:"I would prefer an after-upload check" I fully agree on this only in very few cases as script or plugin only duplicating build in function, or really not working (and obviously for spam , or help request posted as filters ) should be removed by the staff, but only after the author(s) show no intention to take care of it Usually who do scripts/plugins consider with attention question, suggestion ,bug reports and critique so i will suggest to let authors take care of corrections and not enforce them by authority. .if not for few extreme cases "If not in extreme cases"...i use here a real example, somebody posted a "gaussian blur" plugin, and never replied to who asks "what the advantage respect the built in Gaussian blur filter" In a similar case after a quick test (in this case to check if there is some difference with the Gimp "gaussian blur filter"...as a 1 somehow different effects (in this case seems impossible ) 2 additional options, 3) build for not yet covered OS (as Windows or Mac binary not provided by original author) 4 Compatibility with Gap (this may well justify addition of "almost clones" of third party plugin) 5 whatever else can make a difference ( as example...speed: if much quicker is not a clone ) If no one of this points apply to the "clone" then should be possible enforce a removal from the registry or at least mark it , WITH EVIDENCE as "duplicate of .....built in filter/feature" or "duplicate of .....third party plugin/script " or in other case mark as "script for obsolete gimp version", (still somebody post here scripts for gimp .2.2 or 2.4) Or even "Not working : to be fixed" but this case is very rare here, and usually fixed by the authors as soon the problem is reported....
July 13, 2009 - 18:28 — ffaat

regarding: "2 additional options," It is nice for open source because other people can help add features. It would be good if there was a plugin that did much of what was desired and a few new options could be made that the original could be modified rather than another plugin created. Unfortunately that can lead to feature bloat, and differing visions in plugin/scrip visions... -Rob A.
July 22, 2009 - 21:54 — ffaat

I was looking for a duo/tritone script and came across: Sepia Toning 0.4: http://registry.gimp.org/node/17159 Duotone simulation: http://registry.gimp.org/node/110 duotone: http://registry.gimp.org/node/9365 Each crediting the same tutorial for the technique! Each has different features. The first is basic, repeating the tutorial almost exactly. The second performs some curve manipulation on the tint mask. The third has presets for a number of different tints. No wonder users get confused with plugins ;) -Rob A>
July 23, 2009 - 06:24 — PhotoComiX

last 3 scripts now on top of the first page browsing the side 1 Flag wawing http://registry.gimp.org/node/17597 Seems exactly as "Animated Flag" (included also in FX foundry pack) 2 Animation Attribute http://registry.gimp.org/node/17595 Exactly the same then "animation settings by Saulgoode 3 gifsicle There is another script doing the same (now i can't remember the name but i used,) Only difference is that , instead then in Script fu, and so installable on the fly in Win Linux and Mac, those script are in Perl (so unusable on MAC and Win)...and they require not only Perl but also additional libraries C versions may even make sense (because of preview and,sometimes,speed )but i miss the sense of Perl clones of script fu...
August 15, 2009 - 22:41 — Themroc

I wrote "Flag wawing" cause i couldn't find something that satisfied me. The only one i found was "flag flutter" by Karl Ward (where is "Animated Flag"? http://gimpfx-foundry.sourceforge.net/browse26/index_name.html doesn't know about it...).

I did it in perl because i just don't like scheme. Perhaps i'm too dumb to get all those parenthesisis right, fact is, its no fun for me. Sorry for the Windozers, but gimp runs much better on Linux anyway... Even more sorry for the Mac addicts, someone should give em gimp-perl...

"Animation Attributes" is much better than http://gimpfx-foundry.sourceforge.net/browse26/goode-animation-settings.html, because it has a very flexible layer selection, whereas Goode's one works on all layers.

Both "Flag wawing" and "Animation Attributes" do not require additional libraries.

About gifsicle: If i had found it, i wouldn't have written it.

greets

August 15, 2009 - 11:54 — PhotoComiX

At the moment only the author can remove or at least add a warning for obsolete script and plugin...but that do not seems to happen Here a example of obsolete plugin that should be if not removed at least marked as obsolete and no more useful http://www.registry.gimp.org/node/126 From Gimp 2.4 is possible use most of abr (photoshop) brushes so workaround as that have no more sense Even more because the abr loader seems to support much less types of abr then recent Gimp
Subscribe to Comments for "Script Management"

Unless otherwise noted, the rights for the individual plugins are with their respective authors. Logo image by Jakub Steiner.