> the menu/toolbar and shortcut customization. > BTW: If events would be part of this dialog users expect it to be saved with But I explained that is not the case now too (And maybe even for reasons that we haven't thought of as for now.) Would be fine if various items could be combined. The current implementation allows storage. > this dialog has to be saved in one reloadable object (separate files, xml > 5 (How to store data): We postponed the discussion about implementation of Unless people know the name of a uno command and want to search that. But this information does not need to be shown in first > 4 (Search for uno:commands): I would allow to search for function names as a The functions list (left) showing the macro's and the positions list, the events.Īnd 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). > events on a third tab would fit into this workflow. > all options and add it to the right list of selections. > follows the dual-list principle where you select an item on the left list with > 2 (Keep events with customization, perhaps on a third tab): The basic workflow (hmm, and what should 'Add' left below that item list do?) item "Date and time" and then clicking Add would add the new item below there?! The reason: once you have selected a toolbar or menu, the list below shows the items present. 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. > but that's not possible when items are supposed to get sorted up/down. A tree view can be used on the left view with all functions > we need to break down the large list of functions into small pieces to avoid > 1 (Nasty drop-down menu): I agree that this drop down is not really nice. (In reply to Heiko Tietze from comment #3) The caption should be shown to make it clear. Thereupon this shortcut is shown and accepted as new when the dialog is closed.ħ (Button on details dialog): This button opens the dialog for selection of a new image. For example you go to the field that shows ctrl+D and press shift+ctrl+D. I'd say that all customization done in this dialog has to be saved in one reloadable object (separate files, xml sections, references somewhere).īTW: If events would be part of this dialog users expect it to be saved with the menu/toolbar and shortcut customization.Ħ (How to enter a new shortcut): The idea is to focus the input field and accept any key press as new shortcut. Maybe on the details dialog.ĥ (How to store data): We postponed the discussion about implementation of storage since it's not part of the UI. But this information does not need to be shown in first place. Accessibility should be taken into account.Ĥ (Search for uno:commands): I would allow to search for function names as a hidden expert feature. I have no idea how events on a third tab would fit into this workflow.ģ (How to open the details dialog): Good point. (read 'not possible' as 'very unusual').Ģ (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. 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. But we need to break down the large list of functions into small pieces to avoid too much browsing. > Attached a file with ideas, comments, questions.ġ (Nasty drop-down menu): I agree that this drop down is not really nice. If we start any redesign we need to consider all requirements and use cases. Thank you for taking the time to read the text carefully.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |