Re: [Gimp-developer] Announcing Gimpscripter plugin authoring tool, beta prototype

2011-05-10 Thread Sven Neumann
Hi,

On 09.05.11 15:23, lloyd konneker 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.

Sounds great. You should consider to name it GIMPScripter or similar 
though as GIMP is called GIMP and not Gimp.

 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.

It's a pity that GIMP needs to be restarted. We should add API to 
(re)load all or a particular plug-in at run-time.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Plans for input handling in GIMP

2011-05-10 Thread Cedric Sodhi
The current way input devices are setup and handled is flawed in thus
far that it does not allow for any soft of useful flexbility and is, for
a bigger part, not working either.

I suggest to do the following to everything input related on GIMP:

0) Add a Pan tool to the toolbox! Mandatory!

1) Remove everything. Mousebindings. Keyboard bindings. (For the sake of
explaining it from scratch - not necessarily techincally)

2) Add a generic Configure Input Devices options dialog/section, this
unifies Extended Input Devices, Mice and Keyboards and obsoletes the
possiblity of using the event-nodes directly (such things do not belong
in any X program!).

X-Input provides a generic layer for input, Gimp should use it and
align itself to it, not reinvent a broken wheel.

Wherein

Every xinput device as shown by xinput list is represented, devided
into the pointer and keyboard classes. Example (from my xinput):


⎡ Virtual core pointer  id=2[master pointer
⎜   ↳ Virtual core XTEST pointerid=4[slave  pointer
⎜   ↳ Wacom ISDv4 E3 Finger touch   id=10   [slave  pointer
⎜   ↳ Wacom ISDv4 E3 Pen stylus id=11   [slave  pointer
⎜   ↳ SynPS/2 Synaptics TouchPadid=13   [slave  pointer
⎜   ↳ Wacom ISDv4 E3 Pen eraser id=15   [slave  pointer
⎜   ↳ Genius 4D Scroll Mouseid=16   [slave  pointer
⎣ Virtual core keyboard id=3[master keyboard
↳ Virtual core XTEST keyboard   id=5[slave  keyboard
↳ Power Button  id=6[slave  keyboard
↳ Video Bus id=7[slave  keyboard
↳ Video Bus id=8[slave  keyboard
↳ Power Button  id=9[slave  keyboard
↳ AT Translated Set 2 keyboard  id=12   [slave  keyboard
↳ HP WMI hotkeysid=14   [slave  keyboard
↳ Chicony USB Keyboard  id=17   [slave  keyboard

3) Everything handled is generically, the only difference is made
between keyboards and pointers

4) Both, keyboards and pointers provide the following per-device
mapping:

** Key/Button = GIMP Action (as currently exposed through the keyboard
bindings dialog)

5) In addition, pointer devices provide the following:

** Channel mappings (similar to what already exists): That is, every
available channel that is exposed through XInput can be mapped to either
of

Pressure
X
Y
Tilt
...etc, you know the rest...

If a certain value is not mapped on a device (such as Pressure not being mapped
on #16), GIMP will optain the data from the CorePointer

** Associated toolset: If this option is enabled, a tool is associated with
the device and settings for that tool are associated with the device.
That tool is made the active tool, and the settings the active settings ,
when the device is used.

If the option is disabled for a device, the associated tool will be that
of the last-used device, so changing settings or the tool will change
the associated tool / associated settigns for the last used device. If
the last used device doesn't have an associated toolset either, this
recurses to the last used device with an associated toolset.

This option is necessarily enabled for the Corepointer.

** Dedicated Color
** Dedicated Gradient
** Dedicated Pattern
** Dedicated Brush: Similar to above.


kind regards,
Cedric
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Announcing Gimpscripter plugin authoring tool, beta prototype

2011-05-10 Thread lloyd konneker
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 boo...@nc.rr.com
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@lists.XCF.Berkeley.EDU