From The Document Foundation Wiki
Add extra options UI that enables us to simplify and streamline our main options UI without stopping advanced users from still setting those options.
|Call for Proposals||Analysis of Proposals||Shaping Tentative Design||Implementation in Progress||Implemented|
|In Scope||Out of Scope|
- Advanced Options (Panel): A dialog or similar that is separated from the Options dialog (but may be reached from there).
- Gustaf: Gustaf has been using StarOffice and its successors since version 3.0. He knows most things in and out and he'll notice when options are suddenly gone. He also knows that he wants LibreOffice to behave in certain non-standard ways.
- Gregory: Gregory is in charge of the IT infrastructure in a medium-sized company that uses LibreOffice to get office work done. The company is giving their employees laptops to take home and Gregory needs a simple way to get configuration changes out to everyone.
- Gareth: Gareth is a home user of LibreOffice who likes to read somewhat technical blogs. One day, he follows a link on how to make LibreOffice start a whole five percent faster: he is told to go to the Advanced Options and set an option that he doesn't quite understand.
Proposal by Astron
- configuration options are already organized in a highly hierarchical way, options usually read like this:
- Item: /org.openoffice.Office.UI.WriterWindowState/UIElements/States/org.openoffice.Office.UI.WindowState:WindowStateType['private:resource/toolbar/textobjectbar']
- Node name: States
- Property name: Style
- some configuration options contain multiple levels of nodes, some do not contain any nodes, but just properties → no point in adding a column for nodes (which would take up space)
- org.openoffice.Office takes up a large amount of space in some paths and never changes [check: if that actually is true] → cut it out
- a useful separator between items, nodes and properties might be //, since almost anything else that could be used is already used in property names
- logically, the last // would always be for the property
- thus: proposed way of displaying paths:
- this can still lead to unreasonably long option names, in the case that not everything should fit, we should try to cut out the end of the item name (as that is usually the longest part of the name)
- possible columns of the table:
- Locked (might not be necessary, as we can grey out the entry)
- Description (can be very long, so might be better suited to being displayed differently, as in a tooltip/side pane/bottom pane)
- Type, i.e. boolean, string, integer (probably not necessary: booleans are checkboxes, strings accept anything and for integer we can simply ignore anything that is not a number) [check: are there other data types]