Description: UI: Tools; Options. Increase the size of the dialog to be able to expand the list without horizontal scrollbar Steps to Reproduce: 1. Tools -> Options 2. Expand Language settings (and notice the horizontal scrollbar Actual Results: Horizontal scrollbar required Expected Results: Is this really necessary? Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 52a49f9e480ca03e231cfda82640a928393131c9 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: de-DE Calc: CL
Not expert on the maximum size of dialogs and such.. I would love to increase the width a little. Also they Size should by dynamical. So if you increase the size of the options dialog, the horizontal scrollbar should disappear (not sure how the component is called)
Created attachment 165913 [details] Screencast
@Caolan This bug contains 2 elements. Resizing the dialog doesn't increase the size of the 'tree area' (sorry not remembering the component name) Another topic would be, can the dialog become bit wider, so the horizontal scroll bar being less needed in the Tree area .. so content fits better. Hoowever not sure if UX agrees (I think so, but..) Also no idea how this works out for other back-ends etc
Its worth noting that the options dialog has, in practical terms, a near infinite number of pages in it. So, unlike other dialogs, it cannot loop through its pages and pick an optimal dialog size for the entire possible set contents.
We decided to make all dialogs that don't require variable user input (file browsers) non-resizable. Caolan's argument for the exception granted. But I don't see any horizontal scrollbar (neither a control that ever has a scrolling behavior) in the language settings. Some other might be discussed and perhaps details adjusted how it response to resize.
(In reply to Heiko Tietze from comment #5) > We decided to make all dialogs that don't require variable user input (file > browsers) non-resizable. Caolan's argument for the exception granted. > > But I don't see any horizontal scrollbar (neither a control that ever has a > scrolling behavior) in the language settings. Some other might be discussed > and perhaps details adjusted how it response to resize. I'm talking about the 'tree structure organizing the settings' (in expanded state). also they UI Interface language matters..
(In reply to Telesto from comment #6) > I'm talking about the 'tree structure organizing the settings'... Got it. Let's add a splitter (GtkPaned?) between this tree and the panels so the user can resize this part.
The problem isn't in general the sidebar, cause by default I didn't have a scroolbar, but if the vertical scroolbar will be shown, the horizontal scroolbar was also visible (on windows), cause the vertical scroolbar need additional width. If you make the dialog window wider, it doesn't solve the problem, you have to make the "sidebar" wider, which would be the better solution than add a splitter. Or maybe is both possible?
The width of the treeview on the left is set by cui/source/options/treeopt.cxx:493 the "30" of... xTreeLB->set_size_request(xTreeLB->get_approximate_digit_width() * 30, aSize.Height());
is this a duplicate of bug 134791?
(In reply to Timur from comment #10) > is this a duplicate of bug 134791? no this is about the sidebar and bug 134791 is another bug.
(In reply to Caolán McNamara from comment #9) > The width of the treeview on the left is set by > cui/source/options/treeopt.cxx:493 > the "30" of... > xTreeLB->set_size_request(xTreeLB->get_approximate_digit_width() * 30, > aSize.Height()); thanks for the help caolan. I tested it with 35 and it should work.
andreas kainz committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a191dc755c7e529488ab1a172a208db2c16754d3 tdf#137032 make tools-> options sidebar wider It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andreas, is this bug solved? Or is something else still to be done?