Created attachment 178106 [details]
initial layout

Created attachment 178107 [details]
after mouse and back to wallpaper

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.

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 :-)

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?

Created attachment 178113 [details]
journalctl

i added the journalctl output when opening the dialog,
then clicking on mouse
then clicking on wallpaper
then closing it

Does this help?

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

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)

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?

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?

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?

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.

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?

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

(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.

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 :-)

(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.

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

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.

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?

Created attachment 178360 [details]
font settings

please see comment 19

Fonts are the same on all machines, i really like MS Tahoma TTF :-)

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.

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.

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)

Not broken perhaps but this "narrow mode" introduces an inconsistency in Breeze's visual style.

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.

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

Created attachment 181556 [details]
4k-1

Created attachment 181557 [details]
4k-2

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

Are you still able to reproduce this with Frameworks 6.17 or later?

@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.