[Libreoffice-ux-advise] [Bug 88896] Revamp toolbar/menu customization dialog

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=88896

--- Comment #4 from Cor Nouws <cno at nouenoff.nl> ---
Hi Heiko
(In reply to Heiko Tietze from comment #3)

> 1 (Nasty drop-down menu): I agree that this drop down is not really nice. But
> we need to break down the large list of functions into small pieces to avoid
> too much browsing. A tree view can be used on the left view with all functions
> but that's not possible when items are supposed to get sorted up/down. (read
> 'not possible' as 'very unusual').

Looking once more, I must admit that I don't at all understand what the
function of the part is that I gave number 1, the rectangle with Edit and
Macro's.
The reason: once you have selected a toolbar or menu, the list below shows the
items present. And setting the focus on e.g. item "Date and time" and then
clicking Add would add the new item below there?!
(hmm, and what should 'Add' left below that item list do?)

> 2 (Keep events with customization, perhaps on a third tab): The basic workflow
> follows the dual-list principle where you select an item on the left list with
> all options and add it to the right list of selections. I have no idea how
> events on a third tab would fit into this workflow.

The functions list (left) showing the macro's and the positions list, the
events.
And when we expect that people want to save/load the customization also on a
document level to share functionally restricted templates, than that looks as a
logic link with events (that are applied to templates).

> 4 (Search for uno:commands): I would allow to search for function names as a
> hidden expert feature. But this information does not need to be shown in first
> place. Maybe on the details dialog.

Unless people know the name of a uno command and want to search that.
Definitely those users exist.

> 5 (How to store data): We postponed the discussion about implementation of
> storage since it's not part of the UI. I'd say that all customization done in
> this dialog has to be saved in one reloadable object (separate files, xml
> sections, references somewhere).

The current implementation allows storage. So I expect it to available too.
Would be fine if various items could be combined. But I explained that is not
the case now too (And maybe even for reasons that we haven't thought of as for
now.)

> BTW: If events would be part of this dialog users expect it to be saved with
> the menu/toolbar and shortcut customization.

Unless specified different: yes.
Saving all in one (toolbars, menu, short cuts, events) has the disadvantage
that you save customization in one, that can be applied at various levels:
application / module / document.. where does that lead us..?

> 6 (How to enter a new shortcut): The idea is to focus the input field and
> accept any key press as new shortcut. For example you go to the field that
> shows ctrl+D and press shift+ctrl+D. Thereupon this shortcut is shown and
> accepted as new when the dialog is closed.

Still, if the shortcut that I think of, is not available (used already), it's
useful that I can just see what is available. Thus the list.

Now, what just came to my mind, is a really serious question: how can people
assign shortcuts to styles and macro's?
In the current implementation that is done by choosing macro's or styles in the
lists category and item..
I do not see that option in the current design.
For styles, there is of course the wish to make is possible to assign a
shortcut somewhere in the style dialog or window styles and formatting. But
it's only a wish.
One could think of the same in the dialog to run/open a macro.
But then the action of assigning shortcuts is scattered around the place, and
an overview misses.

(Apologies that I've not seen this before. It's hard to find time. But it also
shows how tricky this work is. Even when it's published and some people take
effort to vote, it's not recognized. Hmm :\ )

> 7 (Button on details dialog): This button opens the dialog for selection of a
> new image. The caption should be shown to make it clear.

I thought of that option, but then would have expected to be closer to the icon
shown ;)

Summary: I very much like the easiness of finding functions, and applying
directly or by drag and drop.
That could even be extended by implementing dragging from the functions list to
the toolbar or menu itself (would save selecting the desired one for the
properties list.)
I'm not at all convinced however that restrictions that seem to be planned for
events and shotcuts, will make people happy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.