GIMP Plugin Registry
Home › Forums › Plugins & Scripts

Script Management

July 7, 2009 - 21: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>

‹ Photoshop effect layering batch script that remove layer $name in several xcf-s? ›
Plugins & Scripts
Login or register to post comments
August 15, 2009 - 10:54 — PhotoComiX

Obsolete plugin should be clearly marked

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
Login or register to post comments
July 22, 2009 - 20:54 — ffaat

Another Example

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>
Login or register to post comments
July 23, 2009 - 05:24 — PhotoComiX

other examples

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...
Login or register to post comments
August 15, 2009 - 21:41 — Themroc

No other examples

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

Login or register to post comments
July 11, 2009 - 16:43 — ingo

script management & guidelines

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
Login or register to post comments
July 12, 2009 - 22:50 — PhotoComiX

Quote:"I would prefer an

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....
Login or register to post comments
July 13, 2009 - 17:28 — ffaat

Enhancements to others work

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.
Login or register to post comments
July 9, 2009 - 13:36 — bootchk

Re: script management

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
Login or register to post comments
July 24, 2009 - 15:53 — Anonymous

Plug-in editing program

How about just writing a program that get's launched from within Gimp and recognises the script locations? The user then changes the locations as desired and says go. The program can then edit the scripts (like I would do using notepad). On the next restart of Gimp the script will then appear in the right location. Who feels like coding this? My knowledge of programming sadly limited to html and some basic VB. Sadly this will only work for scripts and not the exe's. Until GIMP features drag and drop menu systems. RiaanR
Login or register to post comments
July 9, 2009 - 19:10 — schumaml

Separating procedures from

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).

Login or register to post comments
July 8, 2009 - 09:10 — Anonymous

Re: Script management

Hi Rob I agree with many of your points. It would be nice if there was a way to put scripts where the user wanted them. Modifying the description would also be useful as sometime the descriptions given by the author is a bit vague. I doubt there would be a way of enforcing rules - a pier / panel review would be a better model for this. Regards RiaanR
Login or register to post comments
July 9, 2009 - 01:07 — PhotoComiX

Re: Script management

i fully agree with most of the points but i think we may better separate 2 main point Point 1 control of the script posted here -- as example i saw recently posted here 1) 1 script (or plugin ? )to create a "gaussian blur" 2)a script (requiring GMIC as dependence) , that only call one of the GMIC filters with its default value (why do not use directly GMIC that may be used also in sort of batch mode?) 3) a script to toggle in/out visibility of all layers (you get the same by Shift+click on a eye icon in the layer windows) 4) a script that in the registration path use the name of its author A weekly or even monthly control of new script/plugin may help to clean out the registry from totally superfluous scripts, and to propose correction for script plugin that have names totally unrelated to their effect 1 or 2 volunteer may be more then sufficient for this task ################################ Point 2 allow user to organize their script menus This instead will require some effort from the core developers. To be more clear : is trivial change a script location..of a single script But will be not realistic expect that most of the users will think to open codes with a text editor to change their register paths And anyway is a PITA do that on many scripts BUT even if a solution will be welcome ,seems more something to discuss on the dev-list then here EXCEPT if somebody may propose a plugin to customize gimp menus location, but i doubt that will be possible from a third party plugin without hacking the core
Login or register to post comments
July 9, 2009 - 01:54 — ffaat

Not what I meant

Funny, but I hadn't considered point 2... allowing users to organize their script registration locations easily (though they can still do it manually). Some example I was thinking of (from recent scripts) -The Layer Effect Scripts initially created a new root menu called "Layer Effects" (which has been, in my opinion, corrected by having it register in the Layers menu of the Image window AND in the layer's dialog) -The script "Selection to Radial Copy" created a new root menu item "ATG->Array" (ATG is the author's initials I think). It should probably be registered under "Selection->Array". -The Layer Groups script package creates a new root level "Layer Groups" menu item. They should probably be "Layer->Groups->whatever" in the image menu and as "Groups->Whatever" in the Layer Dialog Window. - Any scripts that create a new image (i.e. don't work/require on an input image) should all be under the new "File->Create" menu. - Anything registering under "Script-fu" should be placed somewhere based on what it does! - Any script registering in the Xtns menu should be moved elsewhere... this used to be in the toolbox menu back when there was no default image menu, but now that there is one, they should be moved elsewhere. - I'd propose that any script that works on a whole directory of images (batch processing) be registered under a new "File->Batch" menu. And scripts that work on "something" other than an image or layer should be in that "things" menu... a script that modifies/creates a path should be in the path menu... a script that does something with a brush should be in the brush menu, etc... and so on... -Rob A>
Login or register to post comments
July 9, 2009 - 12:02 — PhotoComiX

Script Management

i have a doubt about this: "- Any scripts that create a new image (i.e. don't work/require on an input image) should all be under the new "File->Create" menu." The same script/plugin may well create a new image (is very easy add that option ) AND/OR add a new layer, AND/OR edit/replace the active layer. (To be honest i really will like see all this output options as a standard for most of the scripts and plugins .) But anyway seems the File/Create menu be the most overlooked by most users...simply they do no thought to search there. No objection on the other points ################################# On my point 2 i wonder if the new feature for tagging resources may help to allow users to organize their script registration locations easily: suppose i tag some filter plugin as Enhance ... and i may get then a NEW option to remap their menu according to 1 user's chosen tag In the case of the example to move all scripts/plugins i tagged with "Enhance" in Filter/Enhance menu Or all script tagged "Layer" in the Layer menu and so on
Login or register to post comments
July 9, 2009 - 13:14 — ffaat

Maybe just the latter

I has said "- Any scripts that create a new image (i.e. don't work/require on an input image) should all be under the new "File->Create" menu." Maybe the key is the stuff in the braces - "don't use/require an input image".... If a script creates a new image/layer/whatever FROM an existing image/layer than it is a filter, and belongs there. But if you can open Gimp, and with NO image run the script to get am image it should be under "File->Create", like the logo creation scripts have all been placed. -Rob A>
Login or register to post comments
July 9, 2009 - 18:31 — PhotoComiX

Yes

Yes i already get it is right I just point out that very few think to search script and plugin in some File submenu(without a tip )
Login or register to post comments
July 13, 2009 - 16:54 — aaronsimms

i dont want to bother you

hey do you know how to put scripts in i have to say i tried everything
Login or register to post comments
Syndicate content

You are viewing a mobilized version of this site...
View original page here

Mobilized by Mowser Mowser