GNOME Bugzilla – Bug 75961
Make tooltips less obtrusive
Last modified: 2014-08-03 19:05:34 UTC
Try this. Select the "Applications" menu, then select the Graphics submenu and hold your mouse over any application listed there.. for example, Electric Eyes. The tooltip which appears beneath the selected item completely hides the next two menu items beneath it. (Maybe my tooltip is taller than normal because I use large (14pt) fonts; still, this is poor behavior.) And, no matter where on the menu item I click, the tooltip barely moves; it seems that the roughly the middle of the tooltip is aligned with the mouse. A suggestion for improving this: align the edge of the tooltip with the mouse. This is the Windows XP way, and it make the menus significanly more usable.
Yeah, this would be nice.
Well maybe, but it would be changed in gtk+, not just the panel
The question that comes to mind is... why are there tooltips on menus?
Hmmm! My hunch about why we have tooltips right now is: a) The GNOME2 menu names are not sufficently descriptive, and b) the accessibility guidelines say that widgets should have descriptions. I think we should improve the menu names (I am happy to submit a list of proposed changes, but this will take a few days as I'd like to test my proposals on people), and we should not show the tooltip windows, but should make sure that a description is provided for each menu item to give context to blind/low-sight people. I have emailed Marc from Sun to get his accessibility opinion about this. Will comment again on this bug when he gets back to me. --Anna
*** Bug 77846 has been marked as a duplicate of this bug. ***
Windows 2000 has tooltips on its menus, but they disappear immediately as soon as the mouse moves, even if the cursor stays within the menu item. After that, there is a short delay before it appears again.
*** Bug 79171 has been marked as a duplicate of this bug. ***
I did a quick hack so that tooltips on menu items pop down on motion, and so that the "sticky delay" (pop up immediately) doesn't happen. I think the remaining reasons why the XP tooltips seem a little less annoying than the GTK+ ones are: - They use less padding around the tooltips for menu items then they do for other tooltips. - The tooltips have the left edge at the pointer rather than being centered on the pointer. - The delay might be a bit longer
(Didn't mean to close, just reassign to 2.2.0 with changed Summary)
The hack breaks when the menu item has a submenu. I'll attach a patch to testgtk that adds tooltips to /Preferences/Color. Try getting that tooltip to appear, then quickly move the pointer into it, then click. The menu goes away, but the tooltip window stays on screen. The gnome panel has the same problem.
Created attachment 8499 [details] testcase for tooltips on menu items with submenus
Think you can provide a fix as well Soeren? I don't have time at the moment.
I'll take a look at it tomorrow night (CEST), but of course I can't promise that I'll be able to provide a fix.
Here is a patch that seems to work. It is a bit ugly, though.
Created attachment 8518 [details] [review] patch to make tooltips on menu items with submenus work again
that patch breaks the panel completely (I only tested with testgtk). I don't know if the patch itself is broken of if it just triggers a bug in the panel.
Put in a quick workaround. FIled the issue of menu items with submenus as bug 82373 Mon May 20 12:59:14 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtktooltips.c: Set the private LEAVE_PENDING flag to fix problem where with menu items with submenus, tooltips were getting stuck. (Effectively disables tooltips for menu items with submenus.) (Bug #75961, Soeren Sandmann) * tests/testgtk.c: Set a tooltip on a menu item with a submenu.
*** Bug 82712 has been marked as a duplicate of this bug. ***
*** Bug 95552 has been marked as a duplicate of this bug. ***
In a different bug report, I suggested that the tooltip pop up in a mouse tail-like fashion ... where the bubble help appears in the direction the mouse came from. Even if it won't be considered in this list, I'd like to know if it's possible to do this in gtk2 using the gdk abstraction? Or must it go down to the X level?
I'm not really sure what you mean by your question. GTK+ can position tooltips (that's what we call bubble help) whatever it wants. If you mean fade-in tooltips ... it's not really possible with X, but you can fake it pretty effectively. I did a demonstration patch a while ago.
Hi, Owen. That's exactly what I wanted to know. In order to achieve the desired effect, I have to 1) determine which direction the mouse came from before the tooltip appears, and 2) position the bubble tip in the direction the mouse came from. I now know that positioning the bubble info can be done in gtk2 (so it's application-specific after all and not system-wide). I just have to figure out the position of the mouse prior to firing up the tooltip and I guess that's what I was asking: if there were gdk, gtk2 functions to glean that info from. Unfortunately, now that you mentioned that bubble tip behaviour is app-specific, I might need to do that for all the apps with annoying bubble tip behaviour, :(
Moving various feature enhancements to the 2.4.0 milestone.
Moving this to the menu component, since it seems to be specifically about tooltips on menuitems.
Hi everyone, I was just going through all the bugs marked with the usability keyword, and I was wondering if anyone is still working on making the tooltip for a menu item appear at the right (in left to right language settings) of the cursor? It is still obscuring other menu entries right now since it draws the tooltip centered below the cursor. Ideally it would be immediately adjacent to the the cursor on the right in left to right languages, and I suspect it makes more sense to place it to the left in right to left leanguage settings. This way we obscure much less of the menu at a given time.
Comment on attachment 8499 [details] testcase for tooltips on menu items with submenus Marking attachment as not a patch.
I don't think tooltips on menus are a good idea. closing this