Yes, the Gimpscripter UI and the whole app is thin and could be improved. But thanks for your suggestion, it helps to prioritize. Thanks for the link, AdaptableGimp is exciting. I haven't yet fully explored AdaptableGimp, so what follows are first impressions. AdaptableGimp seems to be a social way to document a TaskSet (what I call a recipe) and to make the TaskSet point-and-clickable. The difference is that TaskSets are not executable as a unit, you still must point and click. This makes sense when the user needs to use the mouse/pointer during the task, e.g. to make a selection or to draw a shape. OTOH when no user mouse/pointer interaction is required, why not make a TaskSet executable? Shouldn't we merge the two ideas of social programming, and point-and-click authoring of executable-as-a-unit recipes? Maybe the users don't want the messiness: "just give me a recipe, I can execute it myself, all that talk about active objects and stacks is confusing." And GEGL is part of the picture, a sequence of image transformations that can be executed as a unit, and controlled as a unit (I have a superficial understanding of GEGL.) Many have suggested improvements to Gimp Registry, to make it more sociable: easier to find, upload, download, and manage plugins. SociableGimp: on-line, community TaskSets AND plugins? Some terminology clarification: Gimpscripter creates what I call shortcuts or wrapper plugins. They are distributable, first-class plugins. They should be sociable. What I call macros are not easily distributable. They are short code fragments built-into Gimpscripter. They are a layer on top of the PDB, to adapt it (eventually some of the macros might migrate to, or be fixed in, the PDB?) They adapt the model presented by the GIMP GUI (e.g. a new layer is in an image) to the model presented by the PDB (e.g., a new layer is not attached.) They don't need to be sociable, once a complete set is created. On Tue, 2011-05-10 at 10:40 +0800, Tim Chen wrote: > Looks good. The UI for creating macros could use some improvement > though, especially some options to remove/insert actions into existed > scripts. Maybe you can reference Michael Terry's recent work on > Adaptable GIMP. > > http://adaptablegimp.org/index.php/How_to_Create_a_Task_Set > > Thanks for sharing. > > Regards, > Tim Chen > http://ht-timchen.org > > On Mon, May 9, 2011 at 9:23 PM, lloyd konneker <bootch@xxxxxxxxx> wrote: > > Announcing a new version of the "Make Shortcut" plugin, now called > > "GimpScripter". It lets you point-and-click create a plugin that calls a > > sequence of plugins, PDB procedures, or macros. It is a plugin authoring > > tool. > > > > Gimpscripter is a Gimp plugin written in Python. It generates Python > > code for a plugin. > > > > The source is at github.com/bootchk/gimpscripter. Installation > > instruction are in the README file. The source includes many readable > > documents such as NEWS, TODO, and a user's manual. You can download a > > tarball or zip there. It is in Python so just install it in the standard > > Gimp directory for plugins, no compilation necessary. > > > > Gimpscripter is still in development. It usually works, but is > > incomplete and could be improved. > > > > Take a look if you are interested in scripting Gimp, as a user or as a > > programmer. > > > > Gimpscripter lets you visually (graphically, point-and-click) implement > > a sequential recipe, for example "Choose this, set that parameter, > > choose that, ..". It doesn't have any control flow statements. > > > > It uses a stack model: it hides a prefix of parameters and references > > them to active objects. > > > > It includes a macro facility and macros for common sequences of > > operations, and to wrap certain PDB procedures with higher-level > > parameter type, e.g. PF_BRUSH instead of PF_STRING for a brush. > > > > Some people suggest using a recorder/playback tool to automate Gimp. > > Scripts from such tools break when the Gimp GUI changes, and the scripts > > are not easily distributable. Gimpscripter is an alternative. > > > > Gimpscripter does have many weaknesses, some of which can be attributed > > to lack of support from the PDB. So it could help guide improvements to > > the PDB (but it might not raise any issues not already known, such as > > not storing defaults.) > > > > I welcome comments or contributions. > > > > Here is an example use, to make a plugin "Stroke selection with > > selection": > > > > Choose "Filter/Gimpscripter" to start Gimpscripter. > > >From the menu pane choose "Edit/Copy". > > Choose "Edit/Paste as/New Brush". > > Choose "Select/To path". > > Choose "Edit/Stroke/Path". > > Enter a name for the plugin, for example "Stroke selection with > > selection". > > Choose the OK button. > > Read the summary and choose the OK button. > > Restart Gimp. > > Open an image and make a selection. > > Choose "Shortcuts/Stroke selection with selection". > > You should see a mobius like effect. > > > > > > _______________________________________________ > > Gimp-developer mailing list > > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
