Description: The dialog of Borders seems to be different from that intended. Steps to Reproduce: 1. Open new Calc. 2. Open Format Cells Dialog. { Ctrl + 1 ]. 3. Select Borders tab. Actual Results: 4. The images in the "Line Arrangement" and "Shadow Style" selection lists are now vertical and take up wasted space. Expected Results: 4. I think the previous side-by-side arrangement is better. Reproducible: Always User Profile Reset: No Additional Info: The same problem is seen in the similar dialog of "Writer". The Linux version does not show this bug. This may have been intended. It may also be related to recent general UI glitches. UI: The drop down arrows are upside down https://bugs.documentfoundation.org/show_bug.cgi?id=167644 Reproducible with [2025-07-23] Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL threaded Not reproduced with [2025-07-23] Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded
Created attachment 201969 [details] sample png
Created attachment 201990 [details] Format Cells -> Borders panel showing Line Arrangement and Shadow Style button bars now oversized panels
Yes the change to an icon view [1] leaves these controls in the Borders panel on too large a field. What had been essentially a button bar with a ValueSet has now been spread out with "native GTK widget" onto a panel. Icons are fine but the panel needs to be constrained. Needs more work. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/187987
(In reply to V Stuart Foote from comment #3) > What had been essentially a button bar with a ValueSet has now been spread > out with "native GTK widget" onto a panel. Icons are fine but the panel > needs to be constrained. For the record, this was changed in commit 4d6429c0368f9b2ec796dd8468defbee194a8b4c Date: Thu Jul 17 14:52:51 2025 +0530 tdf#167536 Switch to IconView for presets and shadows in border page , s.a. discussion in tdf#167536. (It looks fine with gtk3 with a native GtkIconView, but not when the VCL variant of the icon view is used.)
Created attachment 201991 [details] the selected icon in shadow style->position is appearing much wider(horizontal area around the icon) than it should be
Created attachment 201992 [details] Border in gtk3 when setting explicit width to ScrolledWindow
Created attachment 201993 [details] Border in VCL qt6 when setting explicit width to ScrolledWindow
(In reply to Michael Weghorn from comment #4) > (In reply to V Stuart Foote from comment #3) > > What had been essentially a button bar with a ValueSet has now been spread > > out with "native GTK widget" onto a panel. Icons are fine but the panel > > needs to be constrained. > > For the record, this was changed in > > commit 4d6429c0368f9b2ec796dd8468defbee194a8b4c > Date: Thu Jul 17 14:52:51 2025 +0530 > > tdf#167536 Switch to IconView for presets and shadows in border > page > > , s.a. discussion in tdf#167536. (It looks fine with gtk3 with a native > GtkIconView, but not when the VCL variant of the icon view is used.) Thanks Michael :) Yes, it is working fine with gtk3 but not with VCL variant of icon view. I guess, it is due to how the VCL variant of icon view sets the width of each icons. As you can see in my first attachment the selected icon in shadow style->position is appearing much wider(horizontal area around the icon) than it should be. I have also tried to give explicit width to IconView in UI file but it doesn't seem to work. I'm not sure how the VCL variant sets the width of these icons. May be we need some rework there? or I'm not sure if there is already a way to set width for VCL variant and I'm not aware of it. Edit: Another solution I tried is setting up explicit height and width of IconView's parent ScrolledWindow which makes the borders appearing in a single horizontal line but it looks weird both in gtk3(i.e. Border in gtk3 when setting explicit width to ScrolledWindow.png) and in qt6 VCL(i.e. Border in VCL qt6 when setting explicit width to ScrolledWindow.png) Anyway, I believe the ideal way to solve this is reducing the horizontal spacing around the IconView in VCL qt6 but I'm not sure how we can do that.
Created attachment 202000 [details] Demo patch highlighting some potentially relevant places
Created attachment 202001 [details] Screenshot with the demo patch in place
Thanks Parth for looking into this. :-) (In reply to Parth Raiyani from comment #8) > Yes, it is working fine with gtk3 but not with VCL variant of icon view. I > guess, it is due to how the VCL variant of icon view sets the width of each > icons. As you can see in my first attachment the selected icon in shadow > style->position is appearing much wider(horizontal area around the icon) > than it should be. I have also tried to give explicit width to IconView in > UI file but it doesn't seem to work. I'm not sure how the VCL variant sets > the width of these icons. May be we need some rework there? or I'm not sure > if there is already a way to set width for VCL variant and I'm not aware of > it. I don't have a solution at hand either. From looking into the related code now, I agree that something seems to be missing to calculate a proper size for the icons - and the IconView itself. attachment 202000 [details] (to be applied on top of a series of smaller cleanups pending in Gerrit, see series up to https://gerrit.libreoffice.org/c/core/+/188362 ) demonstrates some code areas that might be relevant. That currently unconditionally updates the entry size in SalInstanceIconView::insert (to update the size according to new entry) and adds an `IconView::GetOptimalSize` to report an "optimal size" for the whole IconView, assuming that there is always just a single row of items for simplification of that demo. With that demo patch in place, it looks like attachment 202001 [details] for me with qt6 (and similar with gen). That's of course not meant to be used as is, will break other things, but maybe might give some hint on where to look. > Edit: Another solution I tried is setting up explicit height and width of > IconView's parent ScrolledWindow which makes the borders appearing in a > single horizontal line but it looks weird both in gtk3(i.e. Border in gtk3 > when setting explicit width to ScrolledWindow.png) and in qt6 VCL(i.e. > Border in VCL qt6 when setting explicit width to ScrolledWindow.png) > > Anyway, I believe the ideal way to solve this is reducing the horizontal > spacing around the IconView in VCL qt6 but I'm not sure how we can do that. In my understanding, hard-coding widget sizes is usually not a good idea as it may break in all kinds of ways. Usually the layout code implemented in the widget toolkit should be able to calculate proper sizes depending on the other properties that are set. In the case of GTK, that already seems to work fine. In the case of VCL - our own widget toolkit - something seems to be missing, and it may well be that this needs to be fixed somewhere in the IconView implementation.
(In reply to Michael Weghorn from comment #9) > Demo patch highlighting some potentially relevant places I'm surprised that this issue cannot be solved by rearranging controls in the ui file. (In reply to Michael Weghorn from comment #10) > Screenshot with the demo patch in place LGTM (besides frame and background color)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eaddd58550098fcf73b83507e1fee00eec205856 tdf#167658 Drop IconView's scrolled window parents in "Borders" page It will be available in 26.2.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.
(In reply to Heiko Tietze from comment #12) > (In reply to Michael Weghorn from comment #9) > > Demo patch highlighting some potentially relevant places > I'm surprised that this issue cannot be solved by rearranging controls in > the ui file. Part of the cause is that the vcl IconView control doesn't evaluate all properties the same way that the GTK one (GtkIconView) does. > (In reply to Michael Weghorn from comment #10) > > Screenshot with the demo patch in place > LGTM (besides frame and background color) There's now a pending change series in Gerrit that's meant to upstream what the demo change was showing, series up to https://gerrit.libreoffice.org/c/core/+/189087 Further tweaks can still be done, now maybe even in the .ui file (e.g. exact alignment,...).
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/01d275a80da4a7d1e83fbcd728e1691f48593351 tdf#167658 Update vcl IconView entry size when inserting item It will be available in 26.2.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/478b712ea1cf1883dca3b65343e5c5e0db3b95d9 tdf#167658 vcl: Honor GtkIconView::columns + calc size It will be available in 26.2.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1a655ae0c8c3b78de79eb679a8650574d8199a33 tdf#167658 Reduce icon view size in "Borders" page to what's needed It will be available in 26.2.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.
Created attachment 202236 [details] Screenshot on Windows with changes in place
(In reply to Michael Weghorn from comment #18) > Created attachment 202236 [details] > Screenshot on Windows with changes in place The screenshot shows what it looks like on Windows for me now, which I think should address the issue of using too much vertical space. -> Closing as fixed, please reopen if it doesn't work for you with a daily build containing those changes.
Created attachment 202241 [details] Screencast with kf6 The actual issue is fixed. However, the icons are barely recognizable (isn't much better with 25.2) and the toggle buttons for line arrangements are fake (has been before but less obvious, at least on Qt). The shadow style buttons are true toggles.
(In reply to Heiko Tietze from comment #20) > The actual issue is fixed. However, the icons are barely recognizable (isn't > much better with 25.2) and the toggle buttons for line arrangements are fake > (has been before but less obvious, at least on Qt). The shadow style buttons > are true toggles. I was surprised at the behavior of the "Presets" icons at first as well, but the fact that there selected state isn't permanent seems intended, see my comment in bug 167476 comment 9: > As far as I understand it from looking into the code a bit, the current > logic for the "Presets" control (a ValueSet, like the "Position" one in the > "Shadow Style" section) is that it doesn't have a real permanent selection > state beyond the point in time when it has focus. I.e. it is (currently) > primarily meant to be used to allow a one-time selection of borders that can > then be tweaked later on, by clicking in the "User-defined" control below. > But the preset used to initialize those borders is then (more or less) > discarded and the borders shown in the "User-defined" control are used from > that point on to manage state. (Adding or removing a border in that > "User-defined" control would invalidate any preset previously selected.) (Now this is an IconView, no more a ValueSet, but the general logic is still the same.)