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)