Ok, I feel like helping out here too…
Lets start with no 1.
Could you clarify what you mean by that.
I added 2 of the “not working widgets” and they seem ok to me, but maybe I missunderstand?
Edit
Now that I look at it I can see the clock should maybe be a bit lower though, but the calculator and the distance between the screen border and the panel and calculator looks the same to me.
But add a background to the clock and it looks symmetrical to me.
This is absolutely true, and I really try never to do that.
Absolutely, I think you’re doing well! And it’s tricky because sometimes things like color preferences can reveal cultural factors that ought to be considered too.
Thanks.
Here are two examples - the first one from the Calculator widget in a floating Plasma Panel, the second one from the Folder View widget (after loggin out and in again!).
Can you see the difference?
For another example one could also open the Digital Clock widget, keep it open and slightly move the mouse to the left until you get a mouse over information for e.g. the Volume - unfortunately this was not possible to capture with Spectacle (the mouse over info vanished when Spectacle made a screen shot)…
One can also see the missing coloured icon of two widgets (Folder View and Trash) in both screenshots.
In the second screenshot you can see the too “intense” shadows of the Folder View’s contained icons’ names (this is therefore a bit hard to read compared to the list view - and the shadows have been reduced by the compression of the screenshot: in “real life” they are more intense).
And here is a screenshot from Yakuake with a floating top panel in Plasma 5.27 and one from Plasma 6.
In the second one you can see that the upper half of the first line is missing:
Honestly I have not locked the screen at all in those systems since I installed Plasma 6 (both KDE neon and Arch are only test installations for me…), so:
In KDE neon with Plasma 6.0.0 the screen goes blank when you lock it from the Application Menu and there is no lock screen, only a mouse pointer…
As a workaround I had to switch ttys forth and back to get the lock screen.
In Arch with Plasma 6.0.1 the lock screen works without problems here.
Therefore I now wait until KDE neon gets Plasma 6.0.1, because I don’t know if this already has been resolved in 6.0.1 or if it is a neon bug (I am mainly interested in general Plasma 6 bugs here).
I now understand what you mean by the “trashcan icons”, I have that one too.
But the widgets seems to work for me, although not seemless.
It matters if the panel is floating or not when attaching the calculator and folder view.
It IS very buggy, widgets disappear, just magically pastes on the panel even though I am not even close with the mouse, becomes blank etc.
If I create a 300px big panel at the top (That is what I interpret you do) to slap a widget on it, It pushes the desktop so it becomes scrollable AND I can no longer interact with it on wayland, not move it, not change size, not add stuff to it, not even remove it. Luckily I could remove it on x11.
It also like I mentioned earlier, adds a scrollbar to my desktop so I have to use mousebutton to move my desktop…
I also notice the widgets shrinking if I put them “below the window” too. So yeah, way more work is needed for this to not be an irritating mess to try to set up.
If the distances seemed off, I moved the bottom panel to the top, and then back down and the widgets seemed to connect better.
About yakuake with panel at top works fine for me.
Thank you, but here it does not matter if you add those widgets to an already floating panel or to a de-floated panel and change it to “Floating” later on (both in KDE neon/Plasma 6.0.0 and Arch/Plasma 6.0.1 on two different computers/4 installations and additionally also in VMs).
I am exclusively talking about problems with floating Plasma Panels (the new default) in X11 here.
The unfloated panels’ gaps (there are none) behave like expected in combination with widgets and don’t cut the first line in Yakuake… (I could not quite see in your screenshot because of the black on black - but it seems that your Yakuake example’s top panel is not floating).
I also think that those things are best tested in a new user account with default Plasma and Breeze settings and then to go from there…
Oh, I completely missunderstood. I thought we were doing Wayland here. My bad. 
You are correct, it is not.
I have to go away for a few hours, but when I get home I will try to reproduce this using x11 instead so it actually becomes a fair comparison.
Is the Information panel no longer a feature of Dolphin? See post 33.
The shot below is borrowed from a topic in The FreeBSD Forums:
https://forums.freebsd.org/attachments/2024-03-08-23-40-dolphin-panels-disappeared-png.18431/
Well I have it 
(on Arch)
Thanks. I sped through Bugzilla for KDE, couldn’t find a matching report, I guess it’ll iron itself out in due course.
For now, I’ll continue with Plasma 5 on the same system. No rush.
The shot above is from https://forums.freebsd.org/posts/646504, for anyone who’s interested. Not to hijack this topic 
No worries, we are all a big company here after all 
Here’s a screenshot:
If I’m not mistaken – I didn’t test for long: previews were completely absent in dolphin-devel-24.01.90.
Found 479950 – Dolphin Information Panel not available (RESOLVED FIXED twice), comment 1:
… baloo-widgets. If that’s not available at build time the panel correctly is not available. …
In the meantime Arch has published dolphin 24.02.0-2 which solves the “disappearing panel”-bug even before Gear 24.02.1 has been released - as far as I can tell.
yes, yesterday by including the patch. I’m glad they did because it’s pretty annoying and tbh it’s so obvious I wonder how it had gone unnoticed or not fixed at release. Fwiw, Gear 24.02.1 comes March 21.
Does anybody else have the problem that icons on your desktop resets to the top left of the screen sometimes after reboot on wayland?
I mean the stuff in ~/Desktop
One of the most annoying things so far for me with plasma 6.
The only thing I can tell you is that this has not happened in my openSUSE Tumbleweed with Plasma 6.0.2 in X11 - so far…
Yeah, I suspected it was a wayland thing, this further that suspicion.
JFYI, I’ve proposed fixing the networks/internet categorization error here: categories: reverse location of "Internet" and "Network" text (!303) · Merge requests · Plasma / System Settings · GitLab
Thanks, I appreciate the kind words. On the subject of design and professionalism, it should be no surprise that I also have strong feelings.
You’re not wrong that design is often not taken seriously, but it’s also a problem that we simply don’t get many designers showing up.
I think a source for this is the persistent–and successful–urging in the art & design communities of “don’t work for free!” But that’s exactly what contributing to FOSS means most of the time. Ironically programmers don’t have this culture so much, and so we get a lot more volunteer software developers than we do software designers.
As a result, in general the designers we get in KDE tend not to be experienced professionals but rather students, hobbyists, or just drive-by “you should copy whatever Windows looks like” people. And unfortunately it becomes easy for the devs to ignore them.
Ultimately I think we probably need to hire a professional designer if we want to level up our design capabilities. I worry that it will be painful and traumatic though.
As an example, during last year’s Akademy I got the opportunity to do a design session with Nuno Pinhero, a real professional designer who did a lot of design for KDE in the past. We went over Discover and he pointed out a lot of design issues and errors that became immediately obvious the moment he mentioned them.
Unfortunately, a number of them went deep into the core of how KDE designs apps. For example he pointed out that in Kirigami apps, toolbar content is context-sensitive, but the unified “tools area” visual styling of the toolbar makes it look like the buttons are grouped with the titlebar–which is global in scope–rather than the page beneath it. As a result the context-sensitivity is contradicted by the visual cues in the UI. This was obviously correct, but hearing it felt very depressing to me because I led the effort to unify the titlebar and toolbar contents visually. The obvious conclusion was “well, that was wrong, revert it” and I felt bad. I do still think it looks better than what we had before and it’s been well-received by users. So how can this be resolved? Tough situation.
