Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
2011/5/9 Enrico Schröder : > Hi everybody, > > I've come up with a updated (and more detailed) version of class and > sequence diagrams for the new widget. > > http://enni.userpage.fu-berlin.de/GimpUnitEntry.pdf > > I tried to incorporate some of the comments. Note that all names are > subject to change ;-) > Our now called GimpUnitEntry will be derived from GtkSpinScale and use a > subclass of GtkAdjustment to store its value including the unit > (GimpUnitAdjustment). All synchronisation and live updating of > associated UnitEntries will happen directly between their > GimpUnitAdjustments, thus completely separating everything value-related > from the gui and input. The GimpUnitEntry itself will be just > responsible for display and parsing of entered terms. See use cases and > class diagram for details. Hi Enrico, Good job! Very clear. Some comments, questions and design concerns: * I think the class names are fine. * The parsing should also be perfomed by a non-UI layer and not in GimpUnitEntry so the parsing code can be used in e.g. a script interpreter with no UI dependencies. * Yes, try to reuse GtkAdjustment::value-changed. Only if that doesn't work for some reason should you duplicate the signal in GimpUnitAdjustment. * GimpUnitEntryTable shouldn't derive from GtkTable, because there is no is-a relationship. To convince yourself of that: Can you always replace a GtkTable with a GimpUnitEntryTable? Nope, so you should use composition instead of inheritance. * In case mitch didn't already tell you: The easiest way to create a new class including all C GObject boilerplate is to copy an existing class and do word-wize and case-preserving (like Emacs) search-and-replace. For example, to create GimpUnitAdjustment, copy a GObject inherited GimpDoubleWorded class and first replace 'double' with 'unit', then 'worded' with 'adjustment'. * I've recomended a test-case based development approach before, and now that most of the code will have no UI-dependencies I recomend it even more, as non-UI classes generally are very easy to unit-test. An example of a commit that introduces a non-UI class along with appropriate propotions of documentation and unit tests is this commit: http://git.gnome.org/browse/gimp/commit/?id=9fefa22efe70e484fc7c92708ed8efe023e4d219 By writing unit tests along with your code, productivity goes up a lot when you (or anyone in the lifetime of the project) refactor code, because verifying the class still works takes seconds. * Regarding the use case of entering "1 cm" and getting the result in px, we could use an 'in' keyword like Google. Analogous to "100 SEK in USD", we would have "1 cm in px". That is a future extension though, don't spend time on that yet. * Have you thought about how the image resolution comes into the picture? * Regarding your get_unit() method, an interesting question is what unit an expression like "10px + 1cm" has. * Have you thought about how to connect GimpUnitEntry to the existing GIMP code like the various props helper functions? (See how GimpSizeEntry currently is used) * I don't like how constraints currently are applied, in particular that you require two instance of a constraint when there is only one equation that shall hold. I don't think it is a good idea to make GimpUnitAdjustment (or GimpUnitEntry for that matter) be aware of constraints, because they can potentially be rather complex. It is probably a better idea to take care of constraints one one architectural level above GimpUnitAdjustment (they don't know about constraints, constraints are just being applied to them). * Regarding the contraint case, for a good design, consider how you would support constraints between three numbers (e.g. a = b + c). * Again, I would advice you to focus on the basics. Once the basic functionality is in place, meaning it is good enough for inclusion in a stable GIMP version, we can start working on constraints support. * What program did you make those rather nice sequence diagrams in? Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "GIMP 2.8 schedule on tasktaste.com" ___ 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
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 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] Plans for input handling in GIMP
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
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
