In the tooltip system, "Use 'Show Tooltip' to see full description." is very hard to figure out how to do.

[WraithGlade]

Many times when using ZeroBrane I see "Use 'Show Tooltip' to see full description" show up at the bottom of tooltips.

I've spent a total of probably 2 hours on and off trying to figure out how to actually use 'Show Tooltip' to see more of the tooltips, but despite dozens of search queries on the internet and much effort trying to find it I still can't figure out what it is talking about.

There is no discernible way to do it. There is no 'Show Tooltip' context menu item or button or anything else that I can find. The documentation doesn't have any clear mention of this specific thing anywhere, only of other aspects of tooltips.

From a UI standpoint, the discoverability of such a basic help feature should not be so indecipherable.

Help features should always be blatantly obvious and easily discovered.

So, two things:

1. How does one actually "Use 'Show Tooltip' to see full description"?
2. I strongly recommend that the devs improve this aspect of the UI and/or add info to the online docs about how the feature works.

[pkulchenko]

@WraithGlade, Show Tooltip is a reference to Edit | Show Tooltip menu item, which is also activated by Ctrl-T. Sometimes the descriptions are long, so only some abbreviated version will be shown if the length is above the threshold (as configured by acandtip.maxlength value), but Show Tooltip is always available to show the full version.

Would adding the shortcut to the message help? You can also configure acandtip.maxlength to a large value, which will effectively eliminate the message.

[WraithGlade]

Thanks for the info. 🙂

That explains why I couldn't find it! Conceptually speaking, editing commands are supposed to be commands that either potentially or actually change the state of the content or of the user's setting etc, not commands that only affect the view of something or navigation or provide help. So, the command is essentially incorrectly categorized. Any command that can't ever change the state of the content or of the settings of an editor etc cannot ever properly be called an editing command.

Every time I searched the interface for the command thoroughly my brain was automatically ignoring the editing menu because it was thinking "It's not an editing command and therefore wouldn't ever be under that menu." without me consciously realizing it.

Adding a shortcut to the message would certainly help, because then users seeing the message would immediately be able to expand the tooltip. I think a context menu command is also worth adding, since good help info is so essential to usability and it is likely to be common operation. Also, something should be added to the online docs with the exact phrase so it is searchable online and tells how it works briefly.

I also noticed that the Edit menu has a few other commands that likewise aren't editing commands, specifically the "go to next/prev bookmark commands". Those are navigation commands, not editing commands. This makes me wonder if there should be another menu for navigation or toolbar buttons instead or something like that. Not sure. Just brainstorming. Maybe 'Show Tooltip' should also be moved to the View or Help menus (probably the Help menu I guess). Maybe a modest reorganization of the menus (maybe a couple new menus and/or moving things around and/or toolbar changes).

Anyway though, for any future users searching for this info and coming across the thread, the current hotkey for showing the tooltip is Ctrl-T when your cursor is located on the identifier whose full tooltip info you want to display.

Thanks for the reply and for your time! Have a great day! ZeroBrane is such a great Lua code editor overall! 😎

[pkulchenko]

@WraithGlade, thank you for the detailed feedback! I do occasionally reshuffle menu items for consistency, but I'd also like to keep the number of top menus low, hence the preference for arranging sub-menus where possible.

I made a couple of changes that may address some of the issues you've identified: (1) I added a shortcut to the message and (2) added support for showing the tooltip at the mouse location if there is no identifier under cursor (which made the message more accurate if somebody uses Ctrl-T after mouse over). Give it a try and let me know if this works better for you.

[madmaxoft]

Sorry for hijacking this, but I do need to ask @pkulchenko : Is there a specific reason why you want to keep the number of top level menus low? I'd say the opposite is desirable - top level menu is "easy to reach", while submenus are somewhat difficult to navigate. If your mouse movement is not precise enough, you could, instead of a submenu item, move over another item in the parent menu, thus losing the submenu. Not to mention that discoverability is lower in submenus. On the other hand, nowadays the screens are large enough to accommodate quite a number of top level menus.

[WraithGlade]

@pkulchenko, good to hear! That sounds like an reasonable and effective decision. 😁

A shortcut on the message will be obvious and sufficient for 99% of users probably.

There are of course countless subtly different approaches to solving any UI choice. The exact nuances of what approach to use are of course very subjective generally.

I had one additional random idea: I wonder if perhaps just moving the bookmark commands to the Search menu and then extracting both all of the Search → Navigation submenu commands and all of the Bookmark commands to be directly under the Search menu and then just separating the two groups with a simple dividing line might be better than where they currently are. It may be a little faster to use and Bookmarks are more similar to the Search commands than they are to Edit commands I think. It feels like all those commands would go very well together there since they have very similar functionality (e.g. go to symbol/line/file vs go to bookmark are extremely similar in both nature and intent). Add to that moving Show Tooltip to the Help menu besides the changes you've already made and I think that would pretty much solve the menu organization issues without needing any new menus at all.

That's just another subjective idea though.

Your IDE is awesome and I trust your judgement and tastes for how it should be! 🙂

(PS: I haven't tried the new build yet, but will once I get around to it. I'm currently busy working on other things.)