GNOME Bugzilla – Bug 346992
Inplace tooltips for GtkTreeView cells
Last modified: 2018-02-10 03:41:41 UTC
When the mouse moves over a cell that either a) is partially obscured by the current view position in the scrolled window, or b) contains ellipsized text due to the size of the cell being smaller than its contents a tooltip-like popup should appear in place to show the obscured or ellipsized information. Compare with Windows Explorer's left pane when a folder name is too long.
Created attachment 68627 [details] [review] First public draft implementation This is an 80-90% behavior patch implementing what I desire for this feature. The parts I'm most concerned with: a) due to where do_inplace_tips is called, tips don't appear after all forms of mouse movement when the cursor position says they should. b) the get_content_size modifications to the cell renderers feel a little fragile to me, especially the non-threadsafe implementation for cellrenderertext. c) I've not tested this with any of the subclasses of cellrenderertext. d) I have no clue what I need to do for proper reference counts, so I mostly avoid doing anything. This is undoubtedly wrong. All that said, it's enough to get a very strong idea what behavior I'm asking for by running it with any program that stresses a treeview, including the treemodel demo.
*** Bug 350223 has been marked as a duplicate of this bug. ***
Michael, have you made any further progress on this (towards a 100% implementation)?
Philip, thanks for asking. I have not made any progress on this, as it depends on taking a reserved pointer (Kris indicated he might have other ideas for providing what I needed that for - see the thread at http://mail.gnome.org/archives/gtk-devel-list/2006-August/msg00002.html), and I received no indication that if I took it to 100% there would be any feedback. I still want this, but I've been too lazy to push it. I am willing to update my patch, or continue work on it, if the mentoring, testing, and feedback are likely to come. And doubly willing if it (or a behavioral equivalent) might be used for real.
What was the outcome of http://mail.gnome.org/archives/gtk-devel-list/2006-August/msg00079.html?
None; I didn't take that step.
I just ran into gtk_widget_input_shape_combine_mask which simplifies the bookkeeping considerably - there are no longer any signals the floating tip needs to pass through to the underlying treeview. Kris: where are we on the ability to get the full size of a cell renderer's contents; any hacks or shall I continue prototyping with the reserved signal pointer?
Created attachment 89291 [details] [review] Using input_shape; 95% behavior I just ran into gtk_widget_input_shape_combine_mask which simplifies the bookkeeping considerably - there are no longer any signals the floating tip needs to pass through to the underlying treeview. Kris: where are we on the ability to get the full size of a cell renderer's contents; any hacks or shall I continue prototyping with the reserved signal pointer?
> Kris: where are we on the ability to get the full size of a cell renderer's > contents; any hacks or shall I continue prototyping with the reserved signal > pointer? I am not planning on adding any hacks for this at this point. For 3.0 (in whatever form 3.0 is going to happen is still unknown) I am envisioning to redesign/redo the cell renderer size requisition/allocation. My plan is to experiment with my 3.0 ideas at some point, maybe some of those experiments can be back ported to 2.x if 3.x will take a long time to be realized. As for inplace tooltips; I am still unconvinced that this is a good thing, and if it is whether it belongs in GTK+/GtkTreeView. I think the default tooltips should really suffice (I see no reason why a list/tree widgets needs differently functioning/looking tooltips compared to other widgets) -- API to customize tooltips (in form of positioning, etc) is upcoming.
Is there a better place to do this so other cellrenderer using widgets could do this more easily? The treeview implementation works so well partially because it can reuse the treeviewcolumn rendering functions. Could the updated tooltip functionality be reasonably leveraged to handle this case? Since I saw none of it impacting the treeview code, I'd love to see how it could be used to simultaneously handle inplace tips and per-cell regular tooltips.
Created attachment 104337 [details] [review] Updated to 2.12.5 debian. 98% behavior. Updated patch to fix bitrot due to internal function name changes. Also tweaked behavior to work properly when a treeview has been scrolled horizontally, and to ignore mouse positions outside the visible window (i.e. while scrolling due to rubber-banding). The patch is now against Debian's 2.12.5 package, integrated with quilt, so I can use it on my own machine in all apps.
Created attachment 104854 [details] [review] Updated to 2.12.7 debian. Fixed a misuse of g_return_if_fail that caused stderr spam with custom cellrenderers (such as the revision tree in giggle). There's something wrong with the mouse position checks in gnome-system-monitor, yet they work in similar situations in other programs.
Created attachment 105457 [details] [review] updated for 2.12.8, fixed x offset problems. The x offset problems caused the issues I described last time. Only remaining issues I know of are with non-left aligned columns (and untested thus possibly completely broken rtl behavior).
Created attachment 107391 [details] [review] update to 2.12.9
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.