Created attachment 83486 [details] Screenshot, for everyone that doesn't have a recent nightly handy. Hi Gürkan, Thorsten, so, first things first: when I said on the call today that the Expert Config page of the LibreOffice options was crashing for me – that was my fault. I had not made dev-install again. Mea culpa. Following here are my impressions of the options page: 1. It's pretty nice already – once you can edit options, it should be pretty functional 2. The second most important feature is a filter bar. (I trust you've thought of that already.) If that's not there, people will be very annoyed with this functionality very soon. The filter bar should be the thing initially receiving focus when one first visits the page/opens the window. Also, it should not just work when you're typing the first few letters, it should also search in the middle of words. 3. The first thing that I noticed were the scrollbars – you must have noticed too – I think this page could profit a lot from having its own window, notably one that is resizable. Similar to Thunderbird's implementation of about:config, I'd just add a Expert Configuration button to the Advanced tab of the options. 4. If you think that an own window does not make sense, then please remove the Gtk frame with the "Preferences" label – it really does not add anything in terms of context and steals a few precious pixels of space. 5. Further on the topic of scrollbars, it would be nice if there were only a horizontal scrollbar, just ellipsise ("…") content that tries to be wider. At least, that should be the default – if people want vertical scrollbars, they should be allowed to widen the column headers. 6. Currently, all category headers have little triangles for sorting in them – that doesn't make a lot of sense, only one of them should (otherwise, you are communicating that you are sorting by all column headers). 7. On the topic of those triangles: they look fairly non-standard to me – native theming would be really nice here, but I realise this might be out of scope for this project. 8. The "org.openoffice.Office" part in most(?)/all(?) preferences is a waste of space. It would be cool if this part could be removed somehow. If any extensions use other namespaces, you could just leave their namespacing in – it's a bit inconsistent, but no one will blame us for preferring our own namespace, I hope. 9. I don't know if it makes sense to give string arrays a type of "[]string" – maybe, since there seem to be no other types of arrays, it might make sense to just name this type "array"? 10. If all that is done, we should sacrifice some main-UI options. I think axing all the "experimental" options might be a good first start. :) That's it for right now. Overall, it's very nice work. Thanks to both of you. Astron.
(In reply to comment #0) > 8. The "org.openoffice.Office" part in most(?)/all(?) preferences is a waste > of space. It would be cool if this part could be removed somehow. If any > extensions use other namespaces, you could just leave their namespacing in > – > it's a bit inconsistent, but no one will blame us for preferring our own > namespace, I hope. All of our own configuration schemas are prefixed with /org.openoffice, and a large majority with /org.openoffice.Office. Extensions can bring along schemas with other prefixes. The dialog could unambiguously remove any "/org.openoffice." prefix, say, as unabbreviated paths would always start with "/" and "/" could should never follow a prefix "/org.openoffice.". > 9. I don't know if it makes sense to give string arrays a type of "[]string" > – maybe, since there seem to be no other types of arrays, it might make > sense > to just name this type "array"? At least in principle, there are also other kinds of lists (they're called "lists," not "arrays") apart from string lists (see the complete lists of types e.g. under "ATTLIST prop" at officecfg/registry/component-schema.dtd), though anything but string lists is hardly used, if at all. (I guess the odd name of "[]string" comes from using the name of the UNO type corresponding to the configuration type. The type names appearing in the UI should probably be localized variants of the configuration type names used in officecfg/registry/component-schema.dtd etc.)
(In reply to comment #0) > Hi Gürkan, Thorsten, Hi, I prefer Efe mostly for it is shorter,more memorable and easy to pronounce but OK wit Gürkan too :) Thanks for sharing your opinions this fast firstly. :) So - > 2. The second most important feature is a filter bar. (I trust you've thought > of that already.) If that's not there, people will be very annoyed with > this > functionality very soon. The filter bar should be the thing initially > receiving focus when one first visits the page/opens the window. Also, it > should not just work when you're typing the first few letters, it should > also > search in the middle of words. Yep. On my to do list mentioned it a few times (probably two)on my weekly reports. But there are bigger issues before that. I did this kind of thing before but I was using SQL and should look how to do in LibreOffice. Especially for searching in the middle of words thing. Pretty sure there are a lot of code to use as reference. For 3,4,5: Current interface annoys me too. Probably we will see a few more UI refactoring. But first I need to solve the performance on loading and show all the options instead of some of the randomly chosen. > 6. Currently, all category headers have little triangles for sorting in them > – that doesn't make a lot of sense, only one of them should (otherwise, you > are communicating that you are sorting by all column headers). > I think it would be useful in case you know type of the option but don't know the all of the name etc. You can sort the types, give some part of its toplevel to the filter bar and quick scrolling. It is not the best way to using English here but I hope you can understand what I meant :) > 9. I don't know if it makes sense to give string arrays a type of "[]string" > – maybe, since there seem to be no other types of arrays, it might make > sense > to just name this type "array"? > Type names comes directly through api as Stephen said. And there are other list types like "[]long", "[]short" etc. But as I said not all of the options listed for now. > 10. If all that is done, we should sacrifice some main-UI options. I think > axing all the "experimental" options might be a good first start. :) > > > That's it for right now. Overall, it's very nice work. Thanks to > both of you. > > Astron.
Completely agree with Astron. As for options that should be moved here, there's a list of them at https://wiki.documentfoundation.org/Design/Whiteboards/Options -- all the options marked "Advanced". Currently only the Global Options have been sorted, but hopefully we'll have more sorted soon.
How to disable this editor in enterprise deployment?
Could there be the possibility that a config file in the installation defines which options are 'expert'? (Or maybe that is the case/intention?) If so, could that information be used to hide/show options in the UI? Would be appreciated admins, I guess.
Efe Gürkan YALAMAN committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dde6090b1ac8aecf539e7a779d0f3f42eff3bfb5 fdo#67642 Expert Config Page Moved to its own window The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Now that the Expert Config page has been converted to a standalone (and huge) window, the now redundant “Preferences” header should be removed to save some space (the window’s title is enough).
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1b562139a2e87cce2f189c50a242cf057970551 Related fdo#67642: remove redundant 'Preferences' label to save some space The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=68dc545f9d269c75c3ab2df73b8adf1d2276c240&h=libreoffice-4-3 Related fdo#67642: remove redundant 'Preferences' label to save some space It will be available in LibreOffice 4.3.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Stefan Knorr (astron) from comment #0) > 2. The second most important feature is a filter bar. (I trust you've thought > of that already.) That one’s solved in 5.0 with http://cgit.freedesktop.org/libreoffice/core/commit/?id=1485acc3e86bf6c7e32672c6d36d86e3eb5ddc9e
Hello, I read 10 points but most of them are done. The 5th points isn't done, but the dialog got a new way to represent properties so I think this point is nothing doing.