If we do so we have to clean-up the standard toolbar. For example remove all Insert* commands. Makes the interaction very Shell-like and I don't know if Windows/macOS users are happy with it.

and the HUD is what for LibreOffice?

Hi all,

If the HUD should function like the search bar in Microsoft Office then I absolutely think it should be there. It is such a useful feature for finding functionality, commands, help etc.as it is both used for finding words etc, (akin to Ctrl F) and these activities. You can see the emphasis placed on this due to it being so prominent in the application header.

@Heiko Regarding Mac and Windows users why do you think this would not be wanted? If the HUD would not work like the search bar in MSO then that is a different discussion.

In MSO the Search bar is located in the header bar, as this is not used in LibreOffice would there be an opportunity for this to be a potential placement for the future to make better use of available space?

I will try and join the Design meeting tomorrow where this will be discussed.

Kind regards,

john

(In reply to Cor Nouws from comment #2)
> and the HUD is what for LibreOffice?

Help > Search Command (Shift+Esc)

(In reply to John Mills from comment #3)
> @Heiko Regarding Mac and Windows users why do you think this would not be
> wanted? If the HUD would not work like the search bar in MSO then that is a
> different discussion.

Making space by removing a large part of interactions from the Standard toolbar is unwanted. MSO has the search bar in the headerbar, which wont work (cross-platform) for us.

It may not be possible to add functionality to the header bar currently however a new search icon could be added as an example to the @notebook bar tabbed' interface next to the name of the tabs:

https://www.microsoft.com/en-us/videoplayer/embed/RE3sPA3?pid=ocpVideo1-innerdiv-oneplayer&postJsllMsg=true&maskLevel=20&market=en-us

This could be achieved in a similar manner to Microsoft Outlook 'Tell me what you want to do' in the video above.

Why would adding functionality like this necessitate 'removing a large part of interactions?'

Prior to Microsoft Office 2019 the search functionality (HUD) was a feature of the standard toolbars and not included in the header bar.

The HUD in LibreOffice is a brilliant feature and it should be as simple as possible to find and not 'hidden' behind an obscure shortcut key.

Could the HUD be expanded possible to be functionally similar to the search functionality in MSO?

https://support.microsoft.com/en-us/office/find-what-you-need-with-microsoft-search-in-office-2457d4d8-48a8-4ad4-ab89-5a0657aa8446

We have no obligation to follow any particular Apple or Microsoft feature, or even this Unbutu like HUD implementation.

This bug to provide --text entry into a new combobox on the Standard Toolbar-- is feature creep, where any solution would require either a listbox or continue to use a dialog to hold for

The current and justifiable scope of the HUD is as a *command locator*, plain and *simple* see bug 91874

That said, rather than a hard WONTFIX for this, perhaps simply a Toolbar or NB button UNO action luanching the current HUD dialog, to supplement the <Shift>+<Esc> launch. Beyond that there is little justification for adding functions to the HUD.

(In reply to V Stuart Foote from comment #7)
> listbox or continue to use a dialog to hold for
> 
I'll finish that thought

...to continue to use a dialog to hold and select the search result(s).

(In reply to Heiko Tietze from comment #4)
> (In reply to Cor Nouws from comment #2)
> > and the HUD is what for LibreOffice?
> 
> Help > Search Command (Shift+Esc)

You mean, a text box for search all possible commands?

I think I'm against. Reporter - why not just add a HUD on your own? Why do you believe it needs to be there by default?

I think that the HUD potentially is a great addition to LibreOffice if it would work in a similar way to the search area in Microsoft Office. It is a very user focused feature, I disagree with what the comments that we should have new features because it is 'feature creep.'

If people have used similar functionality in MSO then they will understand just how useful this is and the potential this affords to improve LibreOffice. I believe that this current HUD implementation only listing commands is a first step and it can be expanded to be far more useful. Ultimately the developers will determine where they take this feature.

Adding an UNO command in the Notebookbar interface and toolbar in the 'classic' interface will not detract from any current functionality and be a means to demonstrate this functionality. The LibreOffice community needs to be bold in their approach to new ideas or else the project will stagnate.

(In reply to Eyal Rozenberg from comment #9)

> I think I'm against. Reporter - why not just add a HUD on your own? Why do
> you believe it needs to be there by default?

Because the UNO for it adds the button to the toolbar, but I would prefer the text field

(In reply to Roman Kuznetsov from comment #11)
> (In reply to Eyal Rozenberg from comment #9)
> 
> > I think I'm against. Reporter - why not just add a HUD on your own? Why do
> > you believe it needs to be there by default?
> 
> Because the UNO for it adds the button to the toolbar, but I would prefer
> the text field

A text field to search would be the ideal outcome, but if only a button to open the search is possible then go with that. Better to have something rather than nothing.

Created attachment 180056 [details]
Depicitng the Find toolbar as a potential HUD toolbar.

In my opinion having by default the HUD only accessible by a keyboard shortcut effectively hides it away from the people that would benefit from it the most: novice users that don't know the location of all commands.

Novice users use primarily the mouse and the UI instead of keyboard shortcuts. Yet the HUD is only accessible by a keyboard shortcut. Thus there is no way a novice user that does not even read the Release Notes of each new version know about this great feature.

I know some people are allergic to implement reasonable well-thought UI paradigms if they were first implemented by Microsoft or Apple. But I believe I provided a decent reasoning about why this would be important.

As for providing a HUD (or text field) in the Standard Toolbar or a button. I also agree with Roman that the text field is a better idea. And I don't understand what would be the blocker for this.

As V Stuart Foote mentioned: this can be done by creating a HUD toolbar that could be enabled by default in the Standard Toolbar. I attached a picture of the Standard Toolbar with a potential HUD toolbar, based on the Find Toolbar in the position. Considering that the HUD toolbar is just a search box, it would occupy even less space as my mockup shows.
But a similar box would have to be included in the Tabbed UIs.

(In reply to Pedro from comment #13)
> I attached a picture of the Standard Toolbar with a potential HUD toolbar...

You got a large display... HIG says: aim for 1280px (WXGA is common on notebooks).

(In reply to John Mills from comment #12)

> A text field to search would be the ideal outcome, but if only a button to
> open the search is possible then go with that. Better to have something
> rather than nothing.

My traditional PoV would be: there is the Help menu, that offers what people need (and more).
My more modern personality would say: if it makes users life easier, and it fits in the UI!, let's do it..

(In reply to Cor Nouws from comment #15)
> (In reply to John Mills from comment #12)
> 
> > A text field to search would be the ideal outcome, but if only a button to
> > open the search is possible then go with that. Better to have something
> > rather than nothing.
> 
> My traditional PoV would be: there is the Help menu, that offers what people
> need (and more).
> My more modern personality would say: if it makes users life easier, and it
> fits in the UI!, let's do it..

I think your modern personality is 100% correct on this one ;-) This is a feature that has the future potential to be really helpful and expand the usability of LibreOffice.

(In reply to Heiko Tietze from comment #14)
> (In reply to Pedro from comment #13)
> > I attached a picture of the Standard Toolbar with a potential HUD toolbar...
> 
> You got a large display... HIG says: aim for 1280px (WXGA is common on
> notebooks).

I think the HIG needs to be examined again then if we can't change panels because of a requirement to adhere to 1280px, 1600 x 900 has been a common resolution for at least 5 years now, 1366 x 768 resolution even longer than that.

(In reply to Heiko Tietze from comment #23)
> Just replied to your "...1600 x 900 has been a common resolution". Adding a
> large dropdown either exceed the predefined maximum width - and would be cut
> off for many users - or require to remove a lot interactions. Let's say all
> insert functions.
> 
> Since we want to make the Notebookbar/Tabs the default my take regarding the
> classic UI is therefore WF.

Hi again Heiko,

What I wouldn't like to see is that this is rejected for the 'classic' toolbar with a promise this is implemented in the notebook bar interface and then that doesn't happen.

I would like to see it in both and there is a benefit for users of LibreOffice if it is. If the display is below a certain pixel size can it simply not be displayed? Is the interface responsive enough that this could be done? It seems that the current 800-pixel limit is a detriment for serious changes to the classic  UI.

The HUD pop-up dialog was the result of quikee's implementation of much broader requests for see also bug 91874, it resulted in UNO .uno:CommandPopup assigned to the <Shift>+<Esc> shortcut, and menu resident as the Help -> Search Commands  

The HUD style dialog--offering an input line and a non-resizable panel listing the search results--is rudimentary but functional. With minor tweaks needed--make it resizable and relocatable. It matches the same feature in GIMP.

The UNO can be customized onto other key bindings, or added to any menu/context menu and works now to provide an action to launch the dialog. It was not included in the assemblage of Notebook Bar commands, so currently can't be added there.

No icon was assigned to the UNO, so its text "Search Commands" will appear when added to a Toolbar or Menu.

Additional work, e.g. integrating the index of commands with os/DE search is called for. And, it should be possible to link the dialogs search field to an input combobox suitable for placement on toolbar or menu. 

But merging this command centric search with functions already resident in the Find, and Find & Replace toolbar/dialogs is less compelling and would require major refactoring in both areas.

(In reply to Pedro from comment #13)
> Depicitng the Find toolbar as a potential HUD toolbar.

What if really use Find toolbar for that? With a "special" mode "search for commands" instead of "search for text"?

(Maybe it's a nonsense, I just saw the attachment 180056 [details] wording ant figured that could be a possibility)

(In reply to Mike Kaganski from comment #27)

Or as a sidebar, providing the necessary vertical space for the results.

(In reply to Mike Kaganski from comment #27)
 
> What if really use Find toolbar for that? With a "special" mode "search for
> commands" instead of "search for text"?
> 

Positioning the command search at the bottom (like Firefox's 'Find in page') was suggested for bug 91874. So sure, the Find toolbar might be pressed into service for feeding the dialog.

But then for simplicity we'd suppressed the 'Navigate by' listbox on the Find toolbar, searching text values by default, yet keeping the Find code common for use in the Sidebar Navigator deck.

Seems a slippery slope requiring a lot of rework.

Created attachment 180063 [details]
Possible location for the HUD?

If there is not enough horizontal space at the top of the panel in classic mode could it be moved to the bottom of the LibreOffice Window as in the attached screenshot?

Addressing the comments of Heiko about the length of my display: the beautiful thing of making available the HUD as a toolbar is that you can relocate it to wherever you want it. That's just my preference for a default location.

Other points to consider:
First - width of the HUD field should have minimum resolution into consideration, ofcourse. This was a quick mock-up to help visualize what is being discussed.

Second - I was not aware that we wanted to make the Tabbed UI the default. I believe that the HUD should also be visible in the Tabbed UI, but in there it's harder to decide where to place it.

(In reply to Roman Kuznetsov from comment #11)
> Because the UNO for it adds the button to the toolbar, but I would prefer
> the text field

Ok, well - why not open a bug about that? i.e. having a separate UNO command, or some kind of variant/option to the same UNO command, add the text field? That would be less controvertial...

(In reply to Eyal Rozenberg from comment #38)

AFAICT the OP opened a bug report *about that*, asking to have a *text field* tor the HUD instead of the button *that is only possible now* (mentioned in the bug report title since comment 11); and then you recommend the OP to file a bug report about that? If you imply that *originally* the bug was worded in a different way, that's what bug tracker is: people with different ideas and different understanding file what they want, and then the discussion transforms it into a reasonable shape, which is now exactly "about it".

The topic was on the agenda of the design meeting.

Tagged the opinions of individuals here with plus/minus and we have a tie.

Having means to directly add the search term would be a great benefit (although I remember Tomaz commenting somewhere else that this modification requires some effort). But it comes on cost of space and we either accept the field to be hidden on small screens or remove many commands to make space.

Placing the search field into the header bar as done by MSO is not possible. So we better create a dedicated search tab at the sidebar where 
a) commands are listed in respect to the position at the main menu (as of today),
b) the commands are shown associated with the term whether in the label or the tooltip, and 
c) the search returns occurences in the document where the word is being used (the quick search function).
This will effectively take the quick find into the sidebar.

In request in this ticket, asking for a search field in the Standard toolbar, the recommendation is to close WF.

After the discussion last night it is much clearer the concerns Heiko has, the HUD could be such a brilliant feature to have always visible, it really has a lot of potential. 

I now understand the restriction on a 1280 pixel wide display Heiko raised the concern about. I always use at least 1920 pixels so it is not evident the issues on a small display as I always have plenty of horizontal space. 

I think only for the 'classic' interface it makes sense that it is not always in the main menu, in this case it probably makes sense to have a dedicated area in the side bar as indicated to be Heiko. You could then add additional functionality to this that 'mimics' what is available in MSO.

In the Notebook bar tabbed interface I think it should always be visible if that is technically possible.

It is a real shame that we can't use the header bar for available space in my opinion as this is the ideal location for this to exist.

(In reply to Heiko Tietze from comment #40)
> Placing the search field into the header bar as done by MSO is not possible.

But it is possible to add a magnifier icon next to the Close icon, similar to the current “Update available” icon.

(In reply to Adolfo Jayme Barrientos from comment #42)
> (In reply to Heiko Tietze from comment #40)
> > Placing the search field into the header bar as done by MSO is not possible.
> 
> But it is possible to add a magnifier icon next to the Close icon, similar
> to the current “Update available” icon.

Maybe, but also a different solution. And I'd still prefer the sidebar tab.

(In reply to Adolfo Jayme Barrientos from comment #42)
> (In reply to Heiko Tietze from comment #40)
> > Placing the search field into the header bar as done by MSO is not possible.
> 
> But it is possible to add a magnifier icon next to the Close icon, similar
> to the current “Update available” icon.

Hi Adolfo, I potentially think that is a good idea to consider as the search icon would be always visible no matter the size of the window and would be a strong indication of a type of search command, it could then bring up the HUD from that point. 

My concern was always that the feature was 'hidden' behind an obscure shortcut combination. If it is possible to have a magnifier icon next to the close button are other icons also possible such as open document, undo-redo etc?

Many thanks!

John

> And I'd still prefer the sidebar tab.

@Heiko: My proposal of a control in the menubar row won’t exclude that — it could be a toggle that expands a search UI in the sidebar. I’ll prepare a mockup of what I have in mind.

> If it is possible to have a magnifier icon next to the close button are other
> icons also possible such as open document, undo-redo etc?

@John: Replicating the “quick toolbar” that resides next to MUFFIN tabs in the classic-toolbar interface should be filed as a separate ticket. It is a nice idea; thanks for sharing.