Description: With the traditional UI, the user has the possibility to show not only the standard toolbar, but also others, e.g. the "Track Changes" toolbar and also allowing toolbars to be added as plugins. However, if a different UI view is chosen, such as the NotebookBar (tabbed view) introduced by LO 6.2.0, then these extra toolbars disappear. Just now, I realized that they if the menu bar is still visible, then it is possible to make them visible again through View > Toolbars, but this has taken me a few weeks to realize. Steps to Reproduce: 1. Open LibreOffice 6.2, e.g. Writer in traditional view 2. Make an extra toolbar visible: View > Toolbars > Track Changes 3. Switch to NotebookBar view: View > User Interface > Tabbed Actual Results: Track Changes toolbar is no longer visible. Expected Results: Track Changes toolbar should still be visible. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Workaround: In chosen view, select from menu View > Toolbars > Track Changes (or whatever toolbar is wished). As noted above, it has taken me a long time to realize this. Version: 6.2.0.3 (x64) Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: da-DK (da_DK); UI-Language: en-GB Calc: threaded
Created attachment 149443 [details] Example of Writer with two extra toolbars visible In the screenshot, the plugin toolbar from the Zotero reference manager program is visible in the top, and the LO Track Changes toolbar has been made visible and moved to the left part of the screen.
Created attachment 149444 [details] Screenshot after shift to tabbed view (NotebookBar) - extra toolbars no longer visible Screenshot after shift to tabbed view (View > User Interface > Tabbed). The extra toolbars are no longer visible, because the tabbed view by default starts with no extra toolbars, rather than remembering which toolbars were used in the traditional (Standard Toolbar) view.
Thank you for reporting this bug. I can reproduce this. Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
(In reply to Lars Jødal from comment #2) > Created attachment 149444 [details] > Screenshot after shift to tabbed view (NotebookBar) - extra toolbars no > longer visible > > Screenshot after shift to tabbed view (View > User Interface > Tabbed). The > extra toolbars are no longer visible, because the tabbed view by default > starts with no extra toolbars, rather than remembering which toolbars were > used in the traditional (Standard Toolbar) view. In the place where the NB is you can't add additional toolbars but there is extension support in NB. Yes user settings was not stored somewhere when the layout switch. I add usability team.
Isn't the point of Notebookbars to not use toolbars? Like when inserting a shape you get the Drawing toolbar with the standard UI but a special section at the tabbed UI. And talking about track changes it just have to be implemented in this layout. So my take => WFM (do not show toolbars by default; it can be activated at any time) and GO (implement TC in NBs).
(In reply to Heiko Tietze from comment #5) > Isn't the point of Notebookbars to not use toolbars? Well, yes, but that is not necessarily an option. For toolbars native to LO, such as the Track Changes toolbar, it may be seen as reasonable to expect this to be implemented. It will still require that all such extra functions are incorporated in the Notebookbar. In that case, each such missing functionality in Notebookbar should be registered as a bug, right? But third-party software exists that adds functionality to LO through adding toolbars. An example is the (free) reference software Zotero, which was part of my example in comment 1. It took me quite some time to realize that Zotero could still be used even though it does not incorporate itself in the Notebookbar. Given that LO has changed, not the third-party software (Zotero in this example), it seems fair to put the burden of the change on LO, not on the third-party software. For both native LO functionality and third-party additions, it seems to be case of a single change (making Notebookbar continue to show toolbars not implemented in the bar) versus changing each of the individual cases. Am I overlooking anything in that statement? I have taken the liberty to change the bug status to REOPENED (rather than RESOLVED - NOTABUG). If anybody disagrees in my arguments above for continuing to consider this a bug, please argue again why it is not a bug.
(In reply to Lars Jødal from comment #6) > But third-party software exists that adds functionality to LO... One of the GSoC projects this year made it possible to register at NB as well. I haven't looked into the details and don't know if this require additional effort from the extension supplier in terms of "if toolbarMode addToToolbar else addToNotebook". And I think it is the duty of 3rd party tools to update regularly and comply with modifications, might it the UNO engine or the UI.
Please file tickets for missing functionality at NBs (eg. the mentioned Track Changes, if it's really missing). Resolving this issue as WF - NB intentionally hide toolbars. Oups, it has been resolved but reopened in the past. In this case I never touch the status. Please resolve yourself.
Integrating full Toolbars into the Glade XML based MUFFIN assemblies of the NotebookBar(s) is out of scope. Behavior is as designed and this is NAB. As an RFE it has some merit, and in fact work on the 'Contextual single' NB mode cobbled Toolbar response onto the NB--but that is specific by design. The General use case of adding Toolbars back in is muddled, and best left to specific Extension. This issue is IMHO => WF
Note that when switching back to the traditional menu, these extra toolbars are restored - in that sense they are not forgotten. Good work. (I agree with WONTFIX).