Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
All tools in the current toolbox honor the selection EXCEPT the Move Tool -- though in some cases the selection is not reasonably applicable (eyedropper, zoom, measure, and crop) and in cases of the selection tools, there are modes which modify how selections are treated. To a large extent, all operations in the Layers menu do not honor selections. The notable exceptions are: Transparency-Color To Alpha Transparency-Semi-flatten Transparency-Threshold Alpha Transform-Arbitrary Rotate I would submit that the exceptions listed would best be eradicated: that a general policy be maintained that the default behavior of all functions under the Layer Menu operate on drawables while disregarding any selection and that the default behavior of all tools in the Toolbox honor selections (unless directed otherwise). In order to prosecute such a policy, I would propose the following changes to the current (development) interface: 1) Move the offending Transparency functions to the new Colors menu. 2) Have the Arbitrary Rotate MENU function ignore the selection, operate on the drawable, and not generate a floated layer. 3) Modify the Move Tool so that it operates precisely like the transform tools, honoring the selection and operating on its contents. (This means that a dialog would be presented, numeric offsets possibly enterred, and OK pressed to generate a floated layer). 4) Add a modified mode to ALL of the transform tools (plus/including the new Move Tool) which makes them ignore the selection, operate on the drawable, and not generate a floated layer. Ideally, if the tool is activated in this mode (perhaps CTRL+ALT being held down while the mouse is initially clicked), there should be no dialog presented and the operation take place when the mouse button is released (if the mode is activated after the tool is executed then pressing OK would be required). 5) Restore the option to use the space bar to move the current layer without any dialog being presented. This could readily be implemented by executing the Move Tool in the ignore selection mode. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
I hope I'm not showing my lack of UI skills here, but: On 9/26/06, Carol Spears [EMAIL PROTECTED] wrote: On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote: From: Michael Natterer [EMAIL PROTECTED] While doing so I noticed they are all bad and inconsistent. Indexed images are not currently supported.(heal) Healing does not operate on indexed layers Healing cannot manipulate indexed images. Cannot heal indexed images. Use Image-Mode to change color mode. Points: Instructs how to fix the problem. Concise enough (I hope) to fit translations. Remove Use if constraints prevent users from seeing Image-Mode (the important part) when clipping. And as a general, pie-in-the-sky, comment: It seems that indexed mode editing is cumbersome, confusing, and limited. When core operations are moved into a GEGL, The GIMP should probably lose indexed mode editing (indexed formats autoconvert to/from) and a separate tool be created just for this type of editing. More blue sky: It would be really slick if all GEGL-apps could shuffle images amongst themselves, assuming that interface is intuitive. So that, for example, an indexed editor, a pixel editor, a SVG editor, and a prepress app could all have a 'window' onto a shared image stored in GEGL space. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
