As TDF Wiki page “Development/NotebookBar/Extensions”, an extension can register their own tabs in the Notebookbar. But this is not enough, LO should provide more APIs to allow extension to register not only own tab but also buttons within a tab as File, Home, Insert, etc. to give developers convenience if they don’t want to create a custom tab but want to just create a button.
I guess it's reasonable -> NEW
*** Bug 116532 has been marked as a duplicate of this bug. ***
On this page you will see what happened if a MS Office add-in registered icons on Ribbon interface in Excel 2016: https://docs.microsoft.com/en-us/office/dev/add-ins/design/add-in-commands
*** Bug 122316 has been marked as a duplicate of this bug. ***
Is "adding button to existing toolbar" something that already works with current "old-style" toolbars? Or would extensions always create their own toolbar and add their button there? Could be relevant to keep very similar API for both toolbars and notebookbars and reuse an established (XML)format.
(In reply to jan d from comment #5) > Is "adding button to existing toolbar" something that already works with > current "old-style" toolbars? Yes, the following extension works with this: DCM Direct Colour Management https://extensions.libreoffice.org/extensions/dcm-direct-colour-management Firstly, I can see the special button after I install this extension. But when I switched to tabbed toolbar, the button is disappeared. 版本：6.2.0.1 (x64) Build ID：0412ee99e862f384c1106d0841a950c4cfaa9df1 CPU 线程：4; 操作系统：Windows 10.0; UI 渲染：默认; VCL: win; 区域语言：zh-CN (zh_CN); UI 语言: zh-CN Calc: threaded
If you look at the example on the page cited in comment #1, which in fact is only a proposal how it could look like when it will be developped, there is already included the request for buttons (simply search for button), even though the title does not state this. Otherwise, as I agree with you, the proposal would not be very helpful. But there seems to be no realisation yet, at least I could not find one where I would think it should be placed, namely in parallel to menubar, toolbar etc. You may also note that the text is dated 2016 and has not been edited since. I would gladly add buttons to the notebokbars, even though I do not like seem, if I could.
as there is not only tabbed toolbar the request for extension support in LibreOffice has to be more generic. Idea --------- when you have a look at the notebookbar*.ui files all uno commands are in an sfxlo-NotebookbarToolBox widget, because with an sfxlo-NotebookbarToolBox widget you can define the Toolbar Style (Text only, Icon only, Text below icons, Text beside icons) and the Icon size (no setting use the default setting which the user can change in LibO Settings, Large Toolbar, Menubar, ...) So my request for extension support would be to define extensions with the sfxlo-NotebookbarToolBox widget. Tabbed Toolbar: own Tab where you have sfxlo-NotebookbarToolBox with settings Text below Icons and Large Toolbar icon size Tabbed compact Toolbar: own Tab where you have sfxlo-NotebookbarToolBox with settings Text beside Icons Groupedbar compact Toolbar: own Group called extensions where you have sfxlo-NotebookbarToolBox with icons only layout Implementation -------------- sfxlo-NotebookbarToolBox widget have an specific name e.g. extension1, extension2, ... so everywhere an sfxlo-NotebookbarToolBox widget called extension1 was available in the .ui file the commands from the extension will be shown. open issues: - would be cool if the user can rearrange the extensions (define which is extension1, extension2, ... - it's not possible to say specific command's are more importend and can than be arranged on the home tab. Summery --------- Use NotebookbarToolBox widget with an specific name would be an easy solution and will have an good first implementation, it wan't save all issues (like rearrange commands), but customize the notebookbar is another bug.
I am all for this. It would be essential to improve Notebookbar functionality. By having these functions we could probably even start considering making Notebookbar versions of the traditional layouts.
extension support is available for the Notebookbar. The extension developers have to update there extension according to [1] [1] https://wiki.documentfoundation.org/Development/NotebookBar/Extensions
As system administrator at https://www.diplomaassignments.com/nvq-course-assignment-help what simply makes me feel about that is implementing dynamic pattern approach, goal can be achieved by a diversity which is characterized by stable mythemic range of frequency and it is particularly performed in in-phase movement.
*** Bug 159459 has been marked as a duplicate of this bug. ***
I completely agree with your point. Providing more APIs for extensions to register buttons within existing tabs would indeed offer greater flexibility to developers. This would allow them to integrate their features more seamlessly into the user interface, enhancing the user experience. It's a suggestion that the LO development team should definitely consider. https://geometry-free.com
The problem is that current Notebookbar architecture and how it work makes it extremely hard to customize... There is no "api" for that. Requirement about adding buttons to existing tabs intersects with general customization of notebookbar - adding / removing items from Customization dialog. I was thinking about that in the past. I think the only complete solution would require lot of work and significant change in the approach to building notebookbar. It needs to be more like our toolbars - build from the definition created using some xml / JSON . Then we can modify the list to add something and it means it is possible to dynamically add something to it (currently not possible, you can only hide item). It has also tradeoff - it will be less flexible on the fly (you will need some coding to get new type of a notebookbar layout). Currently it is possible to just edit .ui file in Glade to do anything. We did mistake when planning - we set as a priority usage of .ui file to make it easy to modify by developers/designers (but in fact it's not easy! Andreas knows something about it :) ). But we should rather focus on providing best experience for the end user as a priority - real customization as a requirement. That is what I think from a time perspective :)