Discussed on bug 160598 (In reply to Heiko Tietze from comment #5) > What do you think about making the primary function/s (here Delete, Delete > All) more prominent with tool buttons in the tree? A bit like what was > suggested in > https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may- > support-object-handling-in-libreoffice-draw/ (In reply to Jim Raykowski from comment #9) > Attached is a demo of a WIP follow-up patch. > I agree with you about the button wall. I mainly wanted to see if I was > tracking with your idea. Attached is a demo of a WIP follow-up patch.
Created attachment 193967 [details] demo of mouse over entry exposes main function per icon button rfc on WIP of expose main functions buttons for entry under mouse approach. To me this seems too noisy. Perhaps simply a delete button added on the toolbar in the tool box that has the outline move buttons would be enough. Or, like seen in the first demo, buttons are only shown for the selected entry. https://bugs.documentfoundation.org/attachment.cgi?id=193850
Created attachment 193981 [details] demo of selected entry exposes main functions per icon button The selected entry behavior shown in this demo is less noisy to me than the mouse over behavior shown in the previous demo. Perhaps simply adding a delete button to the toolbar, which is also shown in this demo, may be enough?
I like it a lot. But what exactly is the difference between #1 and #2, except the yellow background? Side note: How about using ellipsis for cut-off text?
(In reply to Jim Raykowski from comment #2) > Created attachment 193981 [details] > demo of selected entry exposes main functions per icon button > > The selected entry behavior shown in this demo is less noisy to me than the > mouse over behavior shown in the previous demo. Perhaps simply adding a > delete button to the toolbar, which is also shown in this demo, may be > enough? I like it. Go with selected entry (can reach via U, D cursor movment?). Agree the on-mouseover is too noisy.
Created attachment 194099 [details] demo of *mouse over selected entry* exposes function buttons Here is a WIP demo using the qt5 vcl plugin that shows function buttons revealed only when the mouse is over a selected entry. I've been doing a lot of poking around vcl::Window, weld::Widget, and awt::XWindow without success of making this work with gtk. WIP patch: https://gerrit.libreoffice.org/c/core/+/167565
(In reply to Jim Raykowski from comment #5) > demo of *mouse over selected entry* exposes function buttons ...if the entry is selected. Looks good to me. I wonder what functions are exposed. Or actually how easy it is to add/remove one from this list.
(In reply to Heiko Tietze from comment #6) > how easy to add/remove Apparently it needs to be defined in the UI file with visibility hard-coded in SwContentTreeFunctionButtonsWindow::ShowForEntry(). Probably over-engineering to make this more flexible with xml/sdi definition and no UI.
Created attachment 194161 [details] demo of exposed UNO's and delete all content type content Here is demo showing exposed UNO's and the ability to delete all content entries of content types. Only the UI file need be edited to add UNO's to a content type or content type content toolbar. As can be seen in the demo, the .uno:FieldDialog needs an icon, you will notice the UNO command label 'Fields' appears that does not fit the toolbar icon spaces. Also, as shown near the start of the demo, NavigateOnSelect needs to be set true for UNO's to appear in the content entry toolbars.
(In reply to Jim Raykowski from comment #8) > demo of exposed UNO's and delete all content type content LGTM. * Insert Bookmark and Hyperlink require a certain position and do not belong to the Navigator, IMO. * The Index family could become amended with the Update function, like other types. And perhaps Edit too. * Footnotes/Endnotes have a settings dialog, not sure if that is worth to add here. * Edit Fields in plural doesn't fit well the contextual use case. Different topic, of course. * Design-wise I think the yellow background is meant for testing only. But if made transparent it probably looks odd (in my dark theme case white on blue). I suggest, if easy to realize, to end the highlighting before the actions area. (In reply to Jim Raykowski from comment #8) > Only the UI file need be edited to add UNO's to a content type... Simple enough. > the .uno:FieldDialog needs an icon No issue with Karasa Jaga/Elementary/Sifr but Breeze/Colibre/Sukapura. Reported in bug 154550. For some reason one (not hidden) field is initially disabled (Formatted Dummy Text > field-Number range illustration). After re/sorting it becomes normal.
(In reply to Jim Raykowski from comment #8) > Created attachment 194161 [details] > demo of exposed UNO's and delete all content type content > Thanks Jim! I'm liking it... personally no issue with the black/red icons on a yellow bar, should work both light and dark color themes. And suspect some of the os/DE would choke on fg/bg color to use if not hardcoded. > ... NavigateOnSelect needs to be set true for UNO's > to appear in the content entry toolbars. adding to my checklist of expert config settings to tweak on my profile.
Created attachment 194195 [details] Demo of NavigatOnSelect set true not required for UNO's to appear in content toolbar (In reply to V Stuart Foote from comment #10) > (In reply to Jim Raykowski from comment #8) > > ... NavigateOnSelect needs to be set true for UNO's > > to appear in the content entry toolbars. > > adding to my checklist of expert config settings to tweak on my profile. In WIP patchset 5 the NavigateOnSelect set true requirement has been removed.
Created attachment 194361 [details] Demo of exposing main functions in the tool box area Making the mouse over entry approach work with gtk is currently beyond my hacking abilities. The attached demo shows an alternate approach to exposing main functions by placing them in the area that is currently occupied by the outline move buttons. Even this does not completely solve gtk problems as gtk doesn't use the GtkToolButton Action Name property like the other backends which is useful for UNO commands that are used more than once in a .ui file, i.e, .uno:FrameDialog used by Frames and OLE objects and .uno:FootnoteDialog used by Footnotes and Endnotes.
Good idea to make this action area contextual responsive. It's in fact wasted space currently as the disabled controls don't offer interactions. The inline actions as you show for kf5 have the advantage of being closer to the view and of less mouse movements. If you want to go further with Gtk mouse-over stuff Caolan might have tips.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/94891dce760817686600f3a8d25e5eb735a1a133 tdf#160817 SwNavigator expose main functions for selected entry It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8616a49d37dec0d17bd2355a3cf4cdb447ba6514 tdf#160817 related: fix tooltip-text translatable context assignments It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ac0a497d09d8b4c0b624f788c8db34081fb8caa9 related tdf#160817 SwNavigator: update content functions toolbar It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.