Created attachment 186730 [details] tar file containing layout and l-and-f portions of the theme. *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY I have a layout-template and a look-and-feel that work together to install a top panel, 2 widgets on the desktop and the related wallpaper. When plasma was updated to 6.5, this theme stopped working. Essentially, I can get either the top panel, or the widgets, but not both. If the code for creating the panel and the code for installing the widgets are both present, only the widgets are installed, and the panel is nowhere to be seen. If I remove the code to install the widgets, the panel shows up. I don't know if this is a bug or a change in the API, but over the past month I've tried rearranging the javascript code every way I could think of, and still the same pattern held - either the widgets or the panel but not both. There is a single exception: if I run the theme with both the panel and the widgets code, only the widgets show up, but... if I run plasma-interactiveconsole and execute only "var panel = new Panel;", the panel shows up. Weird. But it does tell me that the code is correctly creating all components. Is there something I'm missing here? STEPS TO REPRODUCE 1. Open SystemSettings->Global Themes 2. Run Bslx_SouthwestCanyon, loading all options OBSERVED RESULT Only the widgets appear on the screen. The top panel is missing. EXPECTED RESULT Both widgets and the top panel should appear. SOFTWARE/OS VERSIONS (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: 6.17.7 KDE Plasma Version: 6.5.2 KDE Frameworks Version: 6.19 Qt Version: 6.10 ADDITIONAL INFORMATION
if you delete the plasma config files plasma-org.kde.plasma.desktop-appletsrc and plasmashellrc and start plasma in a terminal, are there in the debug message some parse errors or warnings from javascript?
I tried to create a template and a lookandfeel with the given files and i appear to reproduce the problem
uh, actually not, i just had wrong metadata format for the layout template, now on master it works fine. can you upload tarballs of the full panel layout template and of the look and feel?
I am glad to finally get noticed. Have continued to try everything I can think of, to no avail. Same issue. If the javascript to add the desktop widget(s) is commented out, the panel appears. If I uncomment the adding of the desktop widgets, the desktop widgets appear, but not the panel. So I know the code for each works. I cannot figure out why they don;t work together. I've gone back and taken another look at the metadata files, and the panel has the ContainmentCategories set to "panel", but the l&f has no ContainmentCategories set, although I tried adding it with a value of "desktop" and had no luck. Anyway, I've tried moving code around, and retesting every time a new plasma component is updated, but nothing changes. Same pattern. I'm at a complete loss as to what might be the issue. In any case, I've tar'ed up the panel and l&f into the following file at the following URL: https://sourceforge.net/projects/bluestarlinux/files/themesrc/bslx-swcanyon-plus-panel.tar.gz It's too big to attach, as are my arch package files, so I put together the bslxPanel and L&F into a local usr/share/plasma directory and tar'ed it up for you. So, to be clear, in the tar file there is a /usr/share/plasma/layout-templates directory and a /usr/share/plasma/look-and-feel directory. I am hoping you can make some progress...
Please be aware that the chunk of code that adds the desktop widgets is under org.bluestarlinux.southwestcanyon/contents/layouts. The file is org.kde.plasma.desktop-layout.js. The addWidget code is inside the for loop. Simply uncomment/comment out the addWidget to test. Thank you for taking a look.
So. Why does nobody want to look into this?
Please read https://pointieststick.com/2023/07/16/where-bugfixes-and-new-features-come-from/ to find out the general answer to that question.
...and understanding that, I've left this here since November. But, from what you've pointed out, it's worse than I thought. Apparently, then, perfectly valid bugs in kde/plasma will not ever get fixed unless it personally impacts a developer and that developer *feels like* fixing it. That doesn't sound like a rousing endorsement of KDE/Plasma - "KDE/Plasma - maybe we fix the bugs if we feel like it!". 'Cause that's pretty much what you're saying...
Yes, resources are limited. Volunteers evidently opted to work on other things that interested them in their precious free time that they donated to KDE, and paid engineers worked on other projects funded by their employers. That's how things work. If this issue is particularly important to you, I'd suggest sponsoring a fix. Some firms that KDE e.V. trusts to handle such requests can be found at https://ev.kde.org/consultants. If that's not an option you're interested in pursuing, I'm afraid you'll need to be patient.
I could see how that might apply if this were a low priority bug, but it's a part of core functionality. If a theme that cannot place a widget and a panel on the screen because of a bug in KDE/Plasma, that's really not a low priority function. I've been doing this since 1984, and any time I've ever posted a bug here, it's been appropriately triaged and dealt with in an appropriately timely manner. I'm not sensing that with this bug report.
Give me an honest answer - if a plasma theme cannot put a widget and a panel on the screen at the same time, what exactly is the use of global themes? And if this bug causes that kind of an issue, it's not a minor bug - it's a bug in some major part of plasma's functionality. A bug introduced in plasma 6.5. It did not exist in plasma in any version prior to that, so it was a bug introduced in v6.5 and hasn;t been fixed. And there is a dearth of explicit documentation where changes occurred between versions. This could be a simple fix for a profoundly disturbing issue because a Plasma developer could probably identify the problem almost immediately, given that this worked perfectly prior to the release of plasma 6.5. I am a systems developer, not a KDE/Plasma developer, so no, I'm not going there.
Basically, global themes are broken. Or not, but who would know since the documentation is so poor. I would think that since global themes are an important part of kde/plasma, that a significant bug that doesn;t allow the simultaneous placement of widgets and panels in a theme should be considered to be a major functional bug.
If all that bugs you've reported in the past have gotten a faster developer response, that's great! I'm sorry this one hasn't. Since you're a developer, you've surely read the license referenced in the header of every file that says there's no warranty. Since you're not volunteering to help fix the issue or fund someone else to do so, I'm afraid all you can do is patiently wait for a developer who is volunteering their own time or paid by someone else to work on the issue. That's how everything in KDE has worked for 30 years. See also https://community.kde.org/Get_Involved/Issue_Reporting#Have_realistic_expectations
I have spent multiple days discovering this bug and then trying to work around it in Plasma 6.6.3 ## Steps to Reproduce 1. Modify the global theme layout in `/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/layouts/org.kde.plasma.desktop-layout.js`. Use Plasma workspace scripting to add widgets to the desktop. In my case I used `org.kde.plasma.icon` which references a desktop file from `/usr/share/applications/firefox.desktop`, for example. 2. Select the Breeze them in System Settings > Colors & Themes > Breeze and agree to apply `[x] Appearance settings` AND `[x] Desktop and windows layout`, then apply ## Observed Results Only the icons appear. The Panel at the bottom does not show. ## Expected Results The panel and the icons should show. ## Analysis 1. No matter how you add the panel and widgets to the desktop, the panel always disappears. It isn't hidden, and it isn't gone. 2. Instead, the panel exist but is assigned to screen -1. This is confirmed by interrogating the object in the `plasma-interactiveconsole`: const panel_list = panels(); print( 'Panel Count is ' + panel_list.length + '\n' ); if ( panel_list.length === 1 ) { const panel_obj = panel_list[0]; print( panel_obj.screen + '\n' ); panel_obj.screen = 0; } 3. Applying `panel_obj.screen = 0` does NOT fix the issue, and on re-run, the value is reverted to -1. 4. The only 100% reliable solution is to add a junk panel, then delete it. The original panel then reappears. const panel_junk_obj = new Panel; panel_junk_obj.remove(); 5. Unfortunately, the add-a-junk-panel trick only works AFTER a layout is applied from the theme, and run in the interactive console. I expect it would also work with a script triggered through qdbus6. 6. I attempted to apply the theme with one big serialized object that included the panel and widgets all at once. This did not affect the fix the behavior; the panel remains on screen -1 as described above. I hope this researcj is useful in resolving this bug.
Thank you very much, Michael. I very much appreciate your analysis. My expertise is with compiled languages, not interpreted ones, so having a place to start is important. I'll see how far I can chase down the screen issue via the plasma-workspace, qt6-base and qt5-scripts source code. I started chasing down the difference between qdbus6 evaluateScript and evaluation via theme setup on startup, but it'll take quite a bit longer by that route. Narrowing it down hopefully will help. I'm at a point where I'm going to go get the 6.4 code, which worked, and determine where the differences are. Perhaps a kde/plasma developer with a background in themes will lend a hand here, now that it's been determined that this is a bug - and I do consider your analysis proof positive that this a plasma bug. Maybe somebody will take it seriously.
Today I've been confirming your results, Michael, and they are confirmed. I was able to make a couple of extra observations that might be important. First, I messed with the screen indices for both the panel and desktop. Changing one of them to 1 and the other to 0, works as expected - the object assigned to screen 1 doesn't appear but can be iterated. The combination that doesn't work, consistently, is when the panel and widget(s) are assigned to the same screen. Simply toggling the single call to addWidget when adding a folder to the desktop, short circuits the panel. One line of code - call to addWidget - obliterates the panel created to be displayed on the same screen. It, in fact, assigns a screen value of -1 to the panel. I'll be taking a close look at addWidget in plasma-workspace. Something there is messing with screen indices. It could in fact be a timing issue, but we'll take a look and see. It would be nice if a developer who knows this code base would take an interest in fixing broken code.
You're welcome Jeff. It does seem the layout template tries to coordinate and process all changes in one go; in fact, I suspect it may be serializing the changes into a single data structure internally. Apparently, the QML code purposely puts the index to -1 as a placeholder with the intention of "coming back to it" later. But it never does. I too have interpolated to find exactly where this occurs, and it is /always/ when one added a widget with a widget with values for its key, x, y, w, and h. I hope that helps.
(In reply to Michael Mikowski from comment #17) > You're welcome Jeff. It does seem the layout template tries to coordinate > and process all changes in one go; in fact, I suspect it may be serializing > the changes into a single data structure internally. Apparently, the QML > code purposely puts the index to -1 as a placeholder with the intention of > "coming back to it" later. But it never does. I too have interpolated to > find exactly where this occurs, and it is /always/ when one added a widget > with a widget with values for its key, x, y, w, and h. I hope that helps. I was able to determine that it's any call to addWidget, with or without parameters, that kills the screen index. Remove the addWidget call and the panel and wallpaper are instantiated perfectly. I'm slowly trying to push through the source code but it's dense with method calls that need to be followed to understand their function, which makes things tricky to try to follow the main line of logic. Again, I'd like to emphasize that help from someone who is familiar with the code base would be useful (not directed at you, Michael). This is, without question, a bug in plasma themes.
I think logically, the issue is not in addWidget, nor its full logic path. I think the issue is that the widget *was* added. Logically, if addWidget was causing the screen issue, then simply setting the panel and desktop/widget screen indices back to 0 after the the call to addWidget should have resolved it, but it didn't. So apparently, the reset is happening after the panel and desktop are created. The screen index is actually not accessed or modified by addWidget. Am looking around now for whatever happens after the theme's javascript is run. Something is changing that screen index and it's not happening within the panel and desktop layout run. Whatever logic is loading the layout must be changing it.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1489
Git commit db10a9d15ab056c8c6d82ecd69ff7614ae616d38 by Marco Martin. Committed on 20/05/2026 at 09:43. Pushed by mart into branch 'master'. Applet: bookeeping of applet's uiReady When a containment adds an applet, it should put it in loadingApplets only if the applet's ui is not ready, not its own. This is actually a Plasma 6 porting issue and the problem is being present for all Plasma 6 releases so far. M +2 -1 src/plasma/containment.cpp M +1 -0 src/plasma/private/applet_p.cpp M +1 -0 src/plasma/private/applet_p.h https://invent.kde.org/plasma/libplasma/-/commit/db10a9d15ab056c8c6d82ecd69ff7614ae616d38
Git commit a0f4e5ad3b1df7a0808809c6308e27fc8f24be08 by Marco Martin. Committed on 20/05/2026 at 09:43. Pushed by mart into branch 'Plasma/6.7'. Applet: bookeeping of applet's uiReady When a containment adds an applet, it should put it in loadingApplets only if the applet's ui is not ready, not its own. This is actually a Plasma 6 porting issue and the problem is being present for all Plasma 6 releases so far. (cherry picked from commit db10a9d15ab056c8c6d82ecd69ff7614ae616d38) c09707b4 Applet: bookeeping of applet's uiReady Co-authored-by: Marco Martin <notmart@gmail.com> M +2 -1 src/plasma/containment.cpp M +1 -0 src/plasma/private/applet_p.cpp M +1 -0 src/plasma/private/applet_p.h https://invent.kde.org/plasma/libplasma/-/commit/a0f4e5ad3b1df7a0808809c6308e27fc8f24be08
Git commit 85269ffd3b602ddf8c447ea283f4e7c10c4b4562 by Marco Martin. Committed on 20/05/2026 at 09:45. Pushed by mart into branch 'Plasma/6.6'. Applet: bookeeping of applet's uiReady When a containment adds an applet, it should put it in loadingApplets only if the applet's ui is not ready, not its own. This is actually a Plasma 6 porting issue and the problem is being present for all Plasma 6 releases so far. (cherry picked from commit db10a9d15ab056c8c6d82ecd69ff7614ae616d38) c09707b4 Applet: bookeeping of applet's uiReady Co-authored-by: Marco Martin <notmart@gmail.com> M +2 -1 src/plasma/containment.cpp M +1 -0 src/plasma/private/applet_p.cpp M +1 -0 src/plasma/private/applet_p.h https://invent.kde.org/plasma/libplasma/-/commit/85269ffd3b602ddf8c447ea283f4e7c10c4b4562
Tested, confirmed, and thank you.