Summary: | Can not pre-configure panel | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | yvan |
Component: | Panel | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | coolix, nate, niccolo.venerandi, niccolo |
Priority: | NOR | ||
Version: | 5.27.2 | ||
Target Milestone: | 1.0 | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
yvan
2023-04-27 15:28:01 UTC
(In reply to yvan from comment #0) > Hi, > > After reading reading the Kiosk documentation > (https://develop.kde.org/docs/administration/kiosk/introduction/), I could > not find a proper way to pre-configure panel to deploy Plasma to users, > while it works for many other settings. > > STEPS TO REPRODUCE > 1. From a fresh user session, configure the panel (in my case pin / unpin > applications to the task manager, disable the clipboard applet). > 2. Copy `~/.config/plasma-org.kde.plasma.desktop-appletsrc` to `/etc/xdg/`. > 3. Create a new user and log in. > > OBSERVED RESULT > Plasma's panel is not pre-configured as intended. > > EXPECTED RESULT > Plasma's panel should contain chosen applications in the task manager, and > clipboard applet should be disabled, as configured in > `/etc/xdg/plasma-org.kde.plasma.desktop-appletsrc`. > > SOFTWARE/OS VERSIONS > Linux/KDE Plasma: Debian 12 testing > (available in About System) > KDE Plasma Version: 5.27.2 > KDE Frameworks Version: 5.103.0 > Qt Version: 5.15.8 > > ADDITIONAL INFORMATION > I have the same issue with many Dolphin settings. For reference, I already > asked with more details and without answer on Discuss [1], KDE users list > [2] and Debian users list [3]. > 1. > https://discuss.kde.org/t/can-not-configure-plasma-bottom-panel-nor-dolphin- > with-kiosk/329 > 2. https://www.mail-archive.com/kde@mail.kde.org/msg06032.html > 3. https://lists.debian.org/debian-user/2023/04/msg00186.html > > Regards, > Yvan Hi! I would suggest pre-configuring a panel through the Plasma API. Specifically: In `/usr/share/plasma/shells/org.kde.plasma.desktop/contents/` you can find `layout.js`. This JS file is run at startup to set up `plasma-org.kde.plasma.desktop-appletsrc`. You can see it says `loadTemplate("org.kde.plasma.desktop.defaultPanel")`. If you look at `/usr/share/plasma/layout-templates`, you can find some default templates - including "org.kde.plasma.desktop.defaultPanel" - and you can create a new one (saving it in e.g. ~/.local/share/plasma/layout-templates). I'm not sure how you could define a specific template for a certain user. Changing the above `layout.js` would work, but it could also be possible to create a new shell that has a different 'layout.js' and fallsback to Plasma Desktop for everything else. You'd then have to change the shell that's run at login with your custom shell. You can also, and this should be easier, do a Look-And-Feel with its own `layout.js`. You'd then have to specify to use that Look-And-Feel for the user, e.g. by modifying `~/.config/plasmarc`. I'm not sure whether that would run `layout.js` upon first startup. Maybe some more expert Plasma dev could have a better approach? Thanks veggero for these explanations! I will have to look at this closer. One requirement for me is to NOT modify any file provided by packages, so that my customization remains after packages upgrades. I have read `/usr/share/plasma/layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js`. It would be interesting to modify it (with the method you describe or another) to add or remove widgets. On the other end, how could we modify widgets default settings? For example, as I said in my original message, how could we: - add or remove programs in `org.kde.plasma.icontasks` - disable clipboard by default in `org.kde.plasma.systemtray` I strongly believe that being able to customize the panel and its widgets is important for enterprise deployment. Hi, (In reply to yvan from comment #3) > I strongly believe that being able to customize the panel and its widgets is > important for enterprise deployment. I second that, this is mandatory for enterprise development. I stumble upon this bug report while searching docs to achieve the same thing. I've found a Gist, written by a KDE contributor, that might help you to achieve what you want using Palsma API: https://gist.github.com/Zren/764f17c26be4ea0e088f4a6a1871f528 Hi! I'm back. This approach isn't super easy, but I do believe I have a solution here. > One requirement for me is to NOT modify any file provided by packages, so that my customization remains after packages upgrades I believe you can install layout packages to `/home/niccolove/.local/share/plasma/layout-templates/` and you won't have any problem there. > On the other end, how could we modify widgets default settings? For example, as I said in my original message, how could we: > - add or remove programs in `org.kde.plasma.icontasks` > - disable clipboard by default in `org.kde.plasma.systemtray` You can do that thanks to the scripting "config" settings. If you open `~/.config/plasma-org.kde.plasma.desktop-appletsrc` you will see the current configuration of all of your panel and widgets. When you create the applet objects for the panel, you can handle its config values either through its config properties (configKeys, configGroups, globalConfigKeys, globalConfigGroups); for some reason the readConfig and writeConfig calls are not exposed to the JS scripting, but that can be changed. You can also create a config group object, which is able to open a file (plasma-org.kde.plasma.desktop-appletsrc, which again contains all the config you need to change), enter its configuration groups (you can find the right ones since you should have the id of the panel and applets you just created) and write to those config. Sadly there's no dedicated documentation about this, but you can see all the classes that handle these things here: https://invent.kde.org/plasma/plasma-workspace/-/tree/master/shell/scripting The ones you're particularly interested in are widget, applet, containment, and configgroup. I'd be open to better documenting this process and making the API a bit easier to use. |