GNOME Bugzilla – Bug 51108
[TRACKING] Hidden tool options (missing docs + should be visible in the UI)
Last modified: 2007-03-07 18:23:50 UTC
I initially wanted to report this as "no way to move a transparent layer" and file it as an enhancement for the Move tool... But while I was writing this report, I re-discovered that pressing Shift while using the Move tool allows one to move the current layer even if it is totally transparent (instead of selecting another layer or displaying the "forbidden" icon as the normal mode of the Move tool would do). So my initial problem is solved, but another bug remains: if you do not try the various modifier keys, you have no way to know that the feature exists. There is currently no help page for the Move tool, and the Tool Options window displays "This tool has no options". Creating the missing help page would solve a part of the problem, but it would also be nice to have this option visible in the user interface (because many users are too lazy to RTFM, and anyway it is difficult for the users to know that they have to look at the help pages if they do not even know if the feature exists). So I am reporting this in the "User Interface" category because I think that all tools (not only the Move tool) with have hidden features that are accessible only via some modifier keys should also have this visible as an option in their Tool Options window, maybe with a reminder for the corresponding modifier key. For example, the selection tools could have some additional options like this: <X> Replace current selection < > Add to current selection (Shift) < > Substract from current selection (Ctrl) It would even be nicer if this part of the window could be dynamically replaced with the options that show the new meanings of Shift and Ctrl once the selection is started: [ ] Constrain ratio to 1:1 (Shift) [ ] Select from center (Ctrl) This would give much more feedback to the user because currently many newcomers are confused by the different meaning of the modifier keys before and after a selection is started. Seeing that the options are changing would help them to learn the interface easily.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Reassigned to current CVS because it's a wishlist item.
2001-11-21 Michael Natterer <mitch@gimp.org> * app/display/gimpdisplayshell-callbacks.c: key press and release events were sent swapped to tools. * app/tools/selection_options.[ch]: added radio buttons for the selection operation (REPLACE, ADD, ...). Partly fixes #51108. * app/tools/gimpselectiontool.[ch]: honor the new tool options stuff. Do evil things in gimp_selection_tool_modifier_key(). * app/tools/gimpbycolorselecttool.[ch]: removed most of the widgets from the by_color_select window because they are all in the selection_options now. * libgimpwidgets/gimpstock.[ch]: added new stock items for the buttons. * themes/Default/Makefile.am * themes/Default/images/Makefile.am * themes/Default/images/stock-button-selection-add.png * themes/Default/images/stock-button-selection-intersect.png * themes/Default/images/stock-button-selection-replace.png * themes/Default/images/stock-button-selection-subtract.png: new stock images. This does not fix it entirely but is the first step... --Mitch
2001-11-26 Michael Natterer <mitch@gimp.org> (...) * app/tools/gimpmovetool.c: some more widgets for hidden tool options (#51108). One more step... --Mitch
2001-11-29 Michael Natterer <mitch@gimp.org> (...) * app/tools/transform_options.[ch] * app/tools/gimptransformtool.c * app/tools/gimprotatetool.c * app/tools/gimpscaletool.c: added widgets for the transform tools' constraints (one more #51108 issue fixed). And one more...
*** Bug 73471 has been marked as a duplicate of this bug. ***
*** Bug 73472 has been marked as a duplicate of this bug. ***
What tools still have hidden options?
I had a look at the features that are still hidden in the UI. Here is a list of the things that I could find. Selection tools: - The tooltip for the icons add/substract/intersect should mention the modifiers associated with each (Shift, Ctrl, Shift+Ctrl). - The modifiers for "select from center" and "1:1 aspect ratio" (Shift and Ctrl) should be mentioned somewhere in the UI. Path tool: - This is still under development so I am not sure about what should be visible in the UI. But for example, the behavior of Ctrl when the pointer is over a node should be documented. Measure: - What does Shift do exactly? - Ctrl and Alt are used for vertical and horizontal constraints. Paint tools (brush, pencil, airbrush): - Ctrl switches temporarily to the color picker - Shift draws a line, Shift+Ctrl draws a line at constrained angles Eraser: - Shift and Shift+Ctrl to draw lines. Clone: - Ctrl to set the source - Shift and Shift+Ctrl to draw lines. Blur/Sharpen and Dodge/Burn - Shift and Shift+Ctrl to draw lines. For both tools, Shift+Ctrl conflicts with the usage of Ctrl for toggling the mode of the tool. As a result, the behavior is usually not what the user wants. We should probably use Alt for toggling the modes. The same could also be done for other tools even if the conflict is less obvious there (e.g., Eraser and all paint tools, for which the order in which one presses Ctrl and Shift leads to two totally different operations). Should I submit a separate bug report about that? Smudge: - Shift and Shift+Ctrl to draw lines. There may be more hidden features, but that's what I could find in a quick test.
I'm happy enough that most of our bases are covered here. All of the really useful hidden features are now in the UI, and I wouldn't be too concerned that "Draw a line" is not in the paint tool options dialog. Propose closing this as FIXED. At worst, this should get bumped to 2.2, and become a tracking bug for individual options that need exposing. Dave.
Would you consider the path tool to be usable without a lot of trial and error, or reading the source code, or reading the docs (still in development)? And the other features, such as how to draw lines at constrained angles, should be documented in the UI even if they are less critical. For a novice user, a feature that is not visible does not exist. If this feature is useful (and I would argue that drawing lines is useful), then it should be made visible to the user.
I've added a lot of help texts in the status bar, that might ease the use of the tool. I am kind of opposed to exposing the modifier functionality to the Tool Options also in parallel, since the behaviour of the combined use of modifiers and buttons in the options is cumbersome. Mainly for communication reasons there should be an exact mapping of modifiers to functionality. It will be a horrible nightmare to write tutorials ("CTRL-click on a curve to add a point") when this is only true when some button in the tool options is in its default state. (This also is a grief I have mit tool-options saving. The current (broken, I know) tendency of the Gimp to stick in the "substract" selection mode when using CTRL-Q to exit and subsequently "not-being-able-to-select-something-whats-wrong-here?" on subsequent starts of the Gimp gives an idea on what might happen when adding more buttons to the tool options.
Yes, the help texts are useful, but there needs to be a bit more consistency accross the various tools. So I would prefer to have this documented in the options dialog. Regarding the multiple modifiers, I agree that the current behavior of the GIMP and how it automatically saves the tool state for the next session can lead to very annoying problems, especially for novice users. But I also think that hiding the options is only making the problem worse, because the user has no way to know what action has caused the tool to switch to a different mode, temporarily or permanently. So it would be better to have all actions of the modifiers visible as separate options in the tool options dialog, and espcially give immediate visual feedback by toggling or (un)checking the corresponding option as soon as the modifier is pressed. This will help the user to know what is affected by what modifier.
IMHO, the path tool is a special case, in that its functionality has opnly started to settle down now, and the keybindings are still not set in stone. As to the other hidden features, I'm not sure that drawing a line or constraining angles should have buttons. It's certainly something to be discussed. So if you would like the paint tools to have straight line & constrained angles, please open a new bug for that. Setting the source for the clone tool is something it would be nice to have an UI for. It is also quite easy to do. This bug as it is is a little vague to allow it to be addressed systematically. There's not one specific issue to be addressed, which is why I suggest splitting it up. Or closing it as done :) Cheers, Dave.
Closing this bug is not an option: that would be like swiping the dust under the carpet and pretending that the problem does not exist. So I will do as you suggest turn this into a tracking bug for each of the issues that I reported initially and in my additional comment on 2003-08-25.
Bumping this, and its dependencies, to 2.2 - exposing the outstanding featurettes before 2.0 is not a priority, and as an interface change it should probably not happen in the stable series. Dave.
Moving back to 1.3.x. Fixing the obvious usability problems is very important in my opinion. Most of us are experienced GIMP users (or even developers of the features that we are using) and we tend to forget how easy it is for new users to get lost or to become confused because some useful (or essential) features are hidden. For example, there are still many users who do not know that they can switch temporarily from a paint tool to the color picker by pressing a single key. And the most famous example: drawing lines is still a FAQ, despite the fact that the feature was added about five years ago. We should try to fix that before 2.0.
I think that the comment that I added a few minutes ago to bug #124025 may be interesting for all tools: the users who tried the path tool and other tools said that they would like to have both ways to display the tool options (status bar and tool options). This was an informal usuability poll that I did a few days ago with several colleague. This was a very small sample (a dozen users) but they were unanimous. I haven't had the time to submit all the dependent bug reports for this tracking bug (more or less following the list shown in the comment that I posted on 2003-08-25) but I will try to do so during the next few days, hoping that I get enough spare time...
This is the same problem as with bug #120973. Perhaps it is important, but no-one is working on it. And I don't think it's a blocker for a pre-release cycle. By placing it in the 1.3 milestone, you are claiming it is. I don't want to go through all of the bugs I changed to the 2.2 milestone, but I would like you to tell me how this is going to get done in the next week. If it slips a week it's not a big deal, but unless you see a way of getting this done in the next week, it's not a blocker, and should be bumped. Until someone says they're doing it, it's not going to get done. Leaving it in the 1.3 milestone awaiting a follow-up from Raphael. Dave.
Changing milestone to 2.0, since it is idiotic having a tracker bug with a milestone earlier than the bugs it is tracking. I still believe that this could be bumped to 2.2. I don't think that 124025 or 124040 should be on the 2.0 milestone at this late stage. But we can postpone that discussion until after we start pre-releases. Dave.
Bumping this to the 2.2 milestone. It's too late to fix this now and it would mean a lot of strings being added. Let's target this for 2.2.
*** Bug 151535 has been marked as a duplicate of this bug. ***
This shouldn't block the 2.2 release.
Just want to add that the Measuretool options aren't visible in the UI too.
Tentatively setting milestone to 2.4 as I have already improved the status bar messages for several tools (bug #124040) and it should be possible to update the other ones soon, making the hidden features more discoverable. Removing dependency on bug #120973, which could be fixed independently.
Raphael, can you please summarize what you think needs to be done or otherwise close this report? It is IMO way too vague to be in Bugzilla in general and on the 2.4 milestone in particular.
Bumping to the 2.6 milestone then.
Considering that I added status bar messages to the measure tool (mentioned in comment #24) and to some other tools recently, I think that the main issues that are still affecting the discoverability of some options are related to the display of the modifiers and mnemonics in the Tool Options tab. Although the current state is not perfect yet, there are much less hidden options than before so there is no need to keep this tracking bug open. I am closing it as FIXED. The remaining issues are covered in bug #155861 and bug #415796.