Bug 499743 - With specific combination of scaling and font settings, Desktop and Wallpaper dialog layout initially opens to narrow view, but then changes to widescreen view after navigating away and back
Summary: With specific combination of scaling and font settings, Desktop and Wallpaper...
Status: REPORTED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Image & Slideshow wallpaper plugins (other bugs)
Version First Reported In: 6.3.0
Platform: Fedora RPMs Linux
: NOR minor
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-10 09:13 UTC by slartibart70
Modified: 2025-08-19 19:09 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
initial layout (74.01 KB, image/png)
2025-02-10 09:14 UTC, slartibart70
Details
after mouse and back to wallpaper (233.43 KB, image/png)
2025-02-10 09:14 UTC, slartibart70
Details
journalctl (57.45 KB, text/plain)
2025-02-10 13:40 UTC, slartibart70
Details
font settings (55.83 KB, image/png)
2025-02-14 13:14 UTC, slartibart70
Details
4k-1 (229.47 KB, image/png)
2025-05-20 09:36 UTC, slartibart70
Details
4k-2 (112.03 KB, image/png)
2025-05-20 09:36 UTC, slartibart70
Details

Note You need to log in before you can comment on or make changes to this bug.
Description slartibart70 2025-02-10 09:13:48 UTC
I have a background picture on my desktop (@125% resolution)
When i open the 'desktop an wallpaper' dialog the layout of the elements shown in the dialog are not correctly positioned.
Just by clicking on 'mouse actions' and then back to 'wallpaper' fixes the layout.

Please see screenshots

Operating System: Fedora Linux 41
KDE Plasma Version: 6.3.80
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2
Kernel Version: 6.12.13-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Comment 1 slartibart70 2025-02-10 09:14:17 UTC
Created attachment 178106 [details]
initial layout
Comment 2 slartibart70 2025-02-10 09:14:50 UTC
Created attachment 178107 [details]
after mouse and back to wallpaper
Comment 3 Justin Zobel 2025-02-10 09:39:18 UTC
I'm unable to replicate this on git master. Can you please create a fresh user account and see if you can replicate the issue there?

Please change the status back to REPORTED when you reply.
Comment 4 slartibart70 2025-02-10 09:44:14 UTC
I just tried on a different machine where only plain color background was active.

Simply open the wallpaper dialog and the layout is broken as in image 'initial layout'

(my first machine has 125% laptop screen plus 4K 100% external screen, AMD graphics
the 2nd machine is a laptop with 110% screen resolution, no secondary monitor, intel+nvidia graphics)

So, not a singular effect on only one laptop :-)
Comment 5 cwo 2025-02-10 10:52:59 UTC
I can't reproduce this on git master or stock Fedora 41 either. Seems to only trigger in specific circumstances.

Do you see anything that might be relevant if you take a look at the logs with "journalctl --user --follow" while opening the dialog?
Comment 6 slartibart70 2025-02-10 13:40:38 UTC
Created attachment 178113 [details]
journalctl
Comment 7 slartibart70 2025-02-10 13:41:20 UTC
i added the journalctl output when opening the dialog,
then clicking on mouse
then clicking on wallpaper
then closing it

Does this help?
Comment 8 slartibart70 2025-02-10 13:52:04 UTC
this looks suspicious?

Feb 10 14:37:48 p14s plasmashell[6857]: file:///usr/share/plasma/wallpapers/org.kde.potd/contents/ui/config.qml:121:9: Unable to assign [undefined] to bool
Comment 9 slartibart70 2025-02-10 14:40:24 UTC
one thing i noticed on another laptop (an old t420)

Here i don't see the layout problem,
but what i see when first opening the dialog is, that the elements move quickly into place (a very subtle effect, but noticeable)
This does not happen when switching between mouse and wallpaper afterwards, then it's instant.

Maybe this moving into place is broken somehow on the other machines?
Btw, both had previously (the p14s still has, the t470 does not any more) a secondary monitor connected.
The t420 from the 3rd test did not (laptop only)
Comment 10 slartibart70 2025-02-10 14:43:14 UTC
oh, and another thing:

The error on p14s (as initially reported) was 'fixable' by clicking on mouse/wallpaper.

This is not fixing it any more... the layout problem is stuck at the bad layout.
Very strange...

Looks like some memory leak or other nasty and difficult to find bug?
Comment 11 cwo 2025-02-10 16:51:42 UTC
Thanks for the log file! Nothing jumps out at me as being a clear culprit (I have most of them as well, and I don't see the issue) although there are certainly some issues that should be fixed even if they don't have immediate bad consequences.

What happens if you try to resize the window?
Comment 12 slartibart70 2025-02-10 16:58:49 UTC
arghhh :-)

good catch... yes, resizing does the trick.

So, all in all the 'default' window size on a 'scaled' screen is just too small to display all the elements in a proper layout.
On a 100% screen (depending on the resolution?) it works

Although i am still tempted to consider this a 'bug', because (like me) you stumble first over the layout, pulling the window's sides is not what immediatey jumps into someones mind, i suppose.

The problem 'feels' related to the area the preview picture covers. If (like @stalenhag) the wallpaper-image proportions change, we have layout problems...
Wouldn't it bee a good idea to have horizontal scrollbars instead of destroying the layout?
Comment 13 cwo 2025-02-10 17:35:17 UTC
This arrangement (everything on an individual line) is what Kirigami (our convergent framework) does when the usual arrangement doesn't fit. It's basically there as a fallback, and for mobile devices. You can't even resize this particular window to be that small usually; it will only happen if you open it on a really tiny screen.

The width of rest of the dialog is about as large as the Stalenhag image even on English (and probably longer on languages like German or Russian), so making the image itself scrollable would at best add a few pixels before it switches to mobile mode.

One problem with having the whole area be scrollable horizontally is that it load individual plugins that have different behavior patters - image for example shows a varying number of columns depending on the available width; we really do not want horizontal scrolling here. So the whole thing would get complex very quickly as things have to switch between scrollable and non-scrollable.
Comment 14 slartibart70 2025-02-10 18:36:24 UTC
i understand...

So, another proposal:
Plasma has somewhere hardcoded defaults for dialog sizes. What about multiplying them with some scaling factor depending on resolution and zoom-factor percentage?
This way we keep small defaults for small screens and  larger defaults for bigger screens?
Maybe (given well thought out factors) we can get rid of these situations where we would need horizontal scrolling by just having dialog sizes that are big enough?
Comment 15 slartibart70 2025-02-10 18:40:57 UTC
i forgot to add:

that are ... initially ... big enough.

Meaning, if you resize them to a smaller window, the layout will adopt even if it looks less nice
Comment 16 cwo 2025-02-11 01:18:29 UTC
(In reply to slartibart70 from comment #14)
> Plasma has somewhere hardcoded defaults for dialog sizes. What about
> multiplying them with some scaling factor depending on resolution and
> zoom-factor percentage?

They already are. Everything except the very foundations (Qt, kwin etc.) operates on logical pixels already, and the lower-level components handle the scaling. To them, it's not like you're scaled by 125%, your screen is 20% smaller.

The dialogs AIUI typically set a minimum size (can't be smaller than that), a default size, and remember the size they had when they were last open (or at least that's how it's supposed to work, there may always be things that are not hooked up correctly). When you open them, it chooses the remembered size or default size as appropriate.

The problem here is that when the screen gets small enough, it will override the minimum size so that it at least fits the screen. With the scaling applied, your screen is small enough in logical pixels that it hits this mode and tries to adapt by reducing the minimum size and switching to the mobile arrangement.  It looks weird to you because only some things hit that.

FWIW, I played around with this on a Fedora live cd earlier, set my screen size to 1200×800 at 150% scaling and could not reproduce this; the dialog still had the normal layout.
Comment 17 slartibart70 2025-02-11 08:15:47 UTC
Well,
thanks a lot for all those explanations and your time.

I think we can close this particular issue, it would be nice if this general(?) problem finds some future resolutions in kirigami/frameworks/plasma/whatever.
Works for me right now, and as always - i learned sth. new :-)
Comment 18 cwo 2025-02-11 09:35:51 UTC
(In reply to slartibart70 from comment #17)
> I think we can close this particular issue, it would be nice if this
> general(?) problem finds some future resolutions in
> kirigami/frameworks/plasma/whatever.
> Works for me right now, and as always - i learned sth. new :-)

I'm still wondering why it ended up this small. Given that you were able to resize the dialog, I take it that it didn't completely fill the screen in its default starting size?

(Part of the problem here may be that it tried to size it too small, this particular dialog does some on-demand component loading as each wallpaper plugin has its own configuration options. Usually in those kinds of situations we have them as separate pages, but I think here it was desired to keep it all together on one page.

It's hard to say though, as I can't seem to reproduce the issue - I guess the conditions need to be just right. My guess is that there is a bug here, but I don't know what exactly it is.
Comment 19 slartibart70 2025-02-11 09:41:36 UTC
yes, maybe it is dependent on the screen resolution?
On the p14s, i have 2880x1800@125% (so there is plenty of space to draw the dialog)
on the t470p, it's 2560x1440@110% (dialog also too small but plenty of screen area)
on the t420 it's 1440x900@100% (or even other scaling factors >100%)... always perfectly sized, no layout problems
Comment 20 Justin Zobel 2025-02-12 03:07:54 UTC
Moving back to reported as it happened. Workarounds aren't bug fixes so we will leave this open until someone can move it to the correct product and it can be investigated properly.
Comment 21 Marco Martin 2025-02-14 12:48:27 UTC
The first screenshot is how the form layout looks if there isn't enough horizontal space. locally i can't reproduce the issue, must be a combination of scale factor/font size.

what is your screen scaling? are the fonts default or have been changed/configured?
Comment 22 slartibart70 2025-02-14 13:14:56 UTC
Created attachment 178360 [details]
font settings
Comment 23 slartibart70 2025-02-14 13:16:13 UTC
please see comment 19

Fonts are the same on all machines, i really like MS Tahoma TTF :-)
Comment 24 cwo 2025-02-14 13:27:40 UTC
I'm working on other things right now, but I did manage to reproduce the layout issue. I suspect that the PotD provider (at least sometimes) is a little wider than the others, and it's not loaded yet when the minimum size is set. So if the window is set to be as small as possible and then the PotD plugin is loaded, the window is too small and it forces the space-constrained version of FormLayout.
Comment 25 Nate Graham 2025-02-19 14:58:20 UTC
It's not really broken; it's just in narrow mode because it calculated that there wasn't enough space to use widescreen mode.

The fact that it changes its mind later is suspicious though, and that part is probably a subtle bug somewhere.
Comment 26 slartibart70 2025-02-22 17:30:28 UTC
This 'miscalculation' is also present in the digital-clock-settings (systray > clock > configure digital clock)

Could this stem from the fact, that different scaling factors are still not properly taken into account when calculating the size?
(laptop: @125%, 4K@100% in my case on p14s)
Comment 27 Justin Zobel 2025-02-23 01:26:15 UTC
Not broken perhaps but this "narrow mode" introduces an inconsistency in Breeze's visual style.
Comment 28 Nate Graham 2025-05-16 15:31:44 UTC
I'll be curious to know if you still hit this with Frameworks 6.14, where some potentially related changes were made to the narrow FormLayout code.
Comment 29 slartibart70 2025-05-20 09:35:47 UTC
on laptop @125%

first opening of the dialog shows the elements nicely positioned (not stuck to the left hand side, but with some space around it).
This looks way nicer. 
If i resize the window (very narrow witdth), then of course elements start at the left-hand side. This is expected (and, they still have some pixels to the left so they don't start directly on the border).
Agreed - this is an improvement, fine for me.

on 4K @100%
The initial opening of the window shows 'plain color'
Select 'picture of the day' and the space is wide enough to have a clear and good looking layout. (attachment '4k-1')

One point of criticism:
In this state, click on 'mouse actions' (ack. with 'discard'), then click back on 'wallpaper' again.

Now, the layout is changed (still looking good, though).
I wonder - previously we had enough space to have a more 'horizontal' layout (4k-1), after mouse/wallpaper clicks the window size did not change, but now the layout seems not to have enough space to render the previous layout? but instead switches to a more 'vertical' layout? (4k-2)

And, if i select 'plain color' and go to 'picture of the day' again, we are back to '4k-1' layout?

This is purely cosmetics now, i know.
Still interesting to see that switching panels does cause such an effect
Comment 30 slartibart70 2025-05-20 09:36:24 UTC
Created attachment 181556 [details]
4k-1
Comment 31 slartibart70 2025-05-20 09:36:42 UTC
Created attachment 181557 [details]
4k-2
Comment 32 slartibart70 2025-05-20 09:38:18 UTC
above tests with recent packages:

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.80
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Comment 33 Nate Graham 2025-08-13 22:39:10 UTC
Are you still able to reproduce this with Frameworks 6.17 or later?
Comment 34 slartibart70 2025-08-19 19:09:35 UTC
@Nate
Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.80
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.1
Kernel Version: 6.15.10-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland

The glitches in the layout are gone, that's for sure
My remarks  in comment #29 are still valid, though.