Version: (using KDE Devel) Installed from: Compiled sources Such tooltips would speed up learning of keyboard shortcuts. It would like like: Refresh (F5) Back (Alt+Left)
I don't get it. The shortcut is listed in the menu. Why a tooltip? I'd go for WONTFIX
Subject: Re: KDE-wide policy of placing shortcuts in tooltips > I don't get it. The shortcut is listed in the menu. Why a tooltip? I'd go > for WONTFIX But if you have icon in toolbar you would never go to menu to see shortcut for action. Shortcuts in tooltips would speed up process of learning those shortcuts. Also this would be configurable (I saw a program with this option - WindowsCommander?).
In my opinion the idea to put shortcuts info into tooltips is a very good one since tooltip are, like shortcuts, specifically for quick access; and in the ideal case both will make the menu unnecessary for common usage allowing the menu to be hidden permanently.
In programs which do have shortcut keys noted in the tooltips, it is one of my favorite features. It is useful almost 100% of the time. It allows me to look at an icon, hover on it, and then never need to move my mouse for that command again. Since I often know an action by its icon on the toolbar better then its name and position in the menu, this makes a big difference (especially in larger apps such as kword). Also, some toolbar options aren't in menus. In KWord, the alignment options are in a dialog box and on the toolbar, so the only way to find keybindings for them is to configure the shortcuts.
Me too I take a full vote for this feature. I LOVE keyboards shortcuts. It's a convenient way to learn them and put keyboard shortcuts to more peoples !! E.g. If a person hate keyboard shortcuts but OFTEN do the same think, after a time he/she can say "hey ! The tooltip says Ctrl+C... I will try. Ho it's magic and quick. I willn't be boring to copy things now :-D (happy person, lol) !". A discussion has been beginned at KDE Usability mailing list : On Sunday 21 March 2004 12:28, Datschge wrote: > Good idea, but this will have to be a new property since last time I checked > the tooltips for toolbar items are at the same time also the text entries for > the toolbar items when text is showed under or next to icons or even solely. > (That's actually a problem in many languages since while one would want a > tooltip to be informative, the resulting text is often too long to be shown > next or instead an icon. Splitting those properties up in separate entities > would be ideal in any case imo.) So, I propose to tell QT because it's also a QT problem. We must call them quicker to have it for QT4 ! Morover, I suggest to have it with this form : "Copy (Ctrl+C)" With the "Copy " in a normal way (Black on my system), and the "(Ctrl+C)" in gray (or mid-ligth) ! It would look great, clear and professional : allowing to directly see the two parts : the action, and then the shortcut if the user want to "analize" (read and learn) it : efficient. Tooltips can be HTML ones, so we just need to convert plain text to HTML and add the colored shortcut. I've joined a mockup of my grayed shortcut (in menu we can distinguish shortcuts by tabulations, I propose to distinguish them with an approx. gray60).
Created attachment 5326 [details] Mockup : Tooltip with shortcut in gray See #5
Not sure if greying out is good idea. In other contexts greying out of text mean action is inactive/inaccessible ATM. > "Copy (Ctrl+C)" "Copy ( Ctrl+C )" Maybe just add space around parenthesis.
As the coloring, spacing, and delimiting are all clearly very controversion, wouldn't it be a little simple to ask for them to be system-wide configurable separate from the rest of the tool-tip? No need to ever change the defaults, but then nobody has to get it right from the start.
Since coloring the key names of shortcuts in tooltips is my idea I'd like to add a mockup as well showing what I was referring to. (Please ignore the part Sebastien quoted about tooltip and icon text not being separated, that turned out to be a misinterpretation on my part and is rather a problem of the current translations, not a technical one.)
Created attachment 5332 [details] Mockup: colored shortcut in tooltip
Re #8: The shortcuts shown in tooltips will have to be separated from the rest of the tooltip text anyway since shortcuts are fully configurable. It doesn't really make sense including the shortcut as part of the pretty much "hard coded" tooltip content when the shortcuts can easily be changed by the user, does it? ;)
> (Please ignore the part Sebastien quoted about > tooltip and icon text not being separated, that > turned out to be a misinterpretation on my part > and is rather a problem of the current > translations, not a technical one.) No : my mockup was another idea : I've well understood your proposition. I just prefere to not have different background color. But I recognize my keyboard shortcut in gray isn't well... recognizable and, as noticed, could allow the user to think it's disabled... But in your mockup, I wish to suggest to also gray the "+" sign : it's too cluttered to have too colors/background color changes (idem : it's IMHO). And as mentionned, a more spaced text + shortcut could have a nice effect (as in menus). So, for me, color the entire "Alt+Right" in background gray (more beautifull, but I recognize we will lost the "Key look") and separate "Forward" and "Alt+Right" with more space...
The 'key' look is the most important part, as such '+' should not be colored since it's not a key which should be pressed (one however could leave it away and just keep sufficient space between different keys). I would not change the text color instead the background color since it's very important to indicate that the shown text has a completely different purpose, different text colors usually only indicate different states like 'disabled', 'error', 'link' etc., not different purposes. Regarding spacing between the tooltip content and the shortcut info we will see what looks best.
> The 'key' look is the most important part, as such '+' should not be colored > since it's not a key which should be pressed (one however could leave it away > and just keep sufficient space between different keys). OK, you're right (color meant different state). So, I propose to re-add the brackets, to say the user that the two (or more) background colored texts are linked together (and not one "linked" to the tooltip texte, for exemple), to be more obvious. So : Copy ([Ctrl]+[C]) With the [] parts are background colored in gray (or another configurable color ? I don't care but if anyone care of that...).
Okay, several comments. 1) Why on earth does it need a background color? Look at the menu. "Ctrl+X" is all it shows for cut. This is not confusing. It is spaced away from the rest, and more importantly, THERE IS NO WAY TO CONFUSE IT WITH THE ACTION. Honestly. The people who will see, 'Cut (Ctrl+X)' and think it means that clicking the button will do 'Cut (Ctrl+X)' are going to be just as confused by the mixture of colors which makes a splotchy tool-tip and generally uglifies the screen! Are the parens not delimitation enough? Even with a set of spaces between them? Why is this an issue? Every program which puts shortcuts into the tool-tips either uses parens to brackets and it works fine! There's no need to make it look ugly, abnormal, and different from the menu.
> Why on earth does it need a background color? > Look at the menu. "Ctrl+X" is all it shows for cut Yes, after all a good spacing is as well... and consistent with the menus, and not clutter the look of KDE. Solved problem ?
BTW - I don't want enforcing of this into all tooltips. Rather provide new class and allow for developer to use them.
Hi, I couldn't find an update on this. Are there changes?
*** Bug 122999 has been marked as a duplicate of this bug. ***
Closing old bugs