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.