dear devs, people offtentimes have documents with the same name in different directories... also, people will offtentimes wonder where on earth a certain document is located... it would be great to see the path info when looking at the recent documents list.. (when the mouse goes over the given file) removable media and/or inaccessible files could be indicated, too... - - - thank you fore developing libreoffice - - -
My take: show it as tooltip... Let's the UX team decide
Can not confirm. On Windows build of 6.2.3.2 and master/6.3.0 both the Start Center -> Recent Files thumbnail views, and the per module File -> Recent Documents list *already* display full path in a tooltip on mouseover! Already => WFM
oh, right!! Closing as RESOLVED NOTABUG
I'm reopening this bug because I think the bug opener means the recent document list in the LibreOffice UI ('Open' toolbar command, etc.) and not in the Start Center. I don't know if it's technically possible to have a tooltip on these recent document entries, but I'm definitively in favour of this idea after a latency time of some seconds to not disturb the normal mouse cursor path.
(In reply to Thomas Lendo from comment #4) > I'm reopening this bug because I think the bug opener means the recent > document list in the LibreOffice UI ('Open' toolbar command, etc.) and not > in the Start Center. > > I don't know if it's technically possible to have a tooltip on these recent > document entries, but I'm definitively in favour of this idea after a > latency time of some seconds to not disturb the normal mouse cursor path. Moving to NEW then...
Huh? On Windows builds... The MRU list (File -> Recent Documents) already includes the file extensions (if any) in its entry. Also, its pop-up tooltip includes full path and file name there as well. Pretty clear => WFM on Windows builds. Folks seeing different on other builds?
oh, wait a second, it works in GTK2 and GEN but not in GTK3, thus, this is a GTK3 only bug... @Caolán, I thought you could be interested in this issue...
Also reproduced in Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; Locale: ca-ES (ca_ES.UTF-8)
https://gitlab.gnome.org/GNOME/gtk/issues/785 no way to set tooltip on a menu item via GMenuModel
I resolved the issue in Lollypop by using a custom menu builder: https://gitlab.gnome.org/World/lollypop/blob/master/lollypop/widgets_menu.py Allows me to add more custom attributes.
I still see no tooltips with file path when hovering on items in the “Open” picklist and File -> Recent Files. I do see the tooltips in the startcenter / welcome screen. Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.utf-8); UI: de-DE Calc: threaded on Ubuntu 20.04.6 LTS
Tooltips with full path for entrys on the menu MRU listing (File -> Recent Documents) continue to WFM on Windows builds. @Michael W, any cycles to poke at this on GTK3/4? Otherwise still seems NOB as noted by Caolán at comment 9
(In reply to V Stuart Foote from comment #12) > Tooltips with full path for entrys on the menu MRU listing (File -> Recent > Documents) continue to WFM on Windows builds. > > @Michael W, any cycles to poke at this on GTK3/4? Otherwise still seems NOB > as noted by Caolán at comment 9 The Gtk issue that Caolán refers to shows that this is a design decision from the Gtk maintainers, so there's nothing to do about that on LO side: https://gitlab.gnome.org/GNOME/gtk/-/issues/785 (If you still feel strongly that this should be possible, you can try to convince the Gtk maintainers, but I personally don't think this is likely to have success.)
(In reply to Michael Weghorn from comment #13) > > @Michael W, any cycles to poke at this on GTK3/4? Otherwise still seems NOB > > as noted by Caolán at comment 9 > > The Gtk issue that Caolán refers to shows that this is a design decision > from the Gtk maintainers, so there's nothing to do about that on LO side: > https://gitlab.gnome.org/GNOME/gtk/-/issues/785 > Understood, but I'd had a peek at what you'd done for Accerciser, seemed germane.
(In reply to V Stuart Foote from comment #14) > Understood, but I'd had a peek at what you'd done for Accerciser, seemed > germane. Do you mean https://gitlab.gnome.org/GNOME/accerciser/-/merge_requests/38 - in particular https://gitlab.gnome.org/GNOME/accerciser/-/merge_requests/38/diffs?commit_id=ea98703d7d9187d9eeb661b42e2832da912263f7 ? That removes the tooltips from the Accerciser menu items as well, because they're no longer supported when moving to the non-deprecated GMenuModel etc. - i.e. Accerciser will lose tooltips the same way. (Sticking to deprecated things isn't an alternative.)
Yep, misread sorry for the noise. And I guess Cédric B's approach of rolling our own from menu model as for the lollypop player is not appealing either.
(In reply to V Stuart Foote from comment #16) > Yep, misread sorry for the noise. No problem, thanks for looking into it. :) > And I guess Cédric B's approach of rolling > our own from menu model as for the lollypop player is not appealing either. In my opinion, the idea is to stick to what the toolkit does. For better or worse, behaving like other native Gtk applications is therefore generally a feature, not a bug. The general options that are available are: * accepting the Gtk behavior * discussing with upstream Gtk * switching to a different VCL plugin (The gen/x11 one shows tooltips on Linux.)