Add Desktop option for Panel Module

[Svenum]

I have two Monitors and I want to add a second Pannel to the second Monitor. Is this possible?

[magnouvean]

I myself also use two monitors, however as of right now you can only configure panels on one screen. I believe this is a limitation on the kde plasma side, as the plasma-scripting API incredibly enough (at least as far as I have found out) doesn't support specifying screens of the panels, they just get assigned automatically. Hopefully such support is added in the future though, and I'll leave this issue open for discussions on solutions when this potentially happens (or if anyone can find a way to get it working as of the current release)

[Svenum]

Any news on this with plasma6?

[FF-AntiK]

I think I managed to do something similar with my plasma 5 setup.
I only need one panel, but it always spawned on a random screen.
So I found a way to define on which screen it will spawn.
Technically it should be possible to adapt this to multiple panels.

In .config/plasma-org.kde.plasma.desktop-appletsrc the panels have an option called lastScreen.
Here's an example of my config:

[Containments][25]
activityId=
formfactor=3
immutability=1
lastScreen=0
location=6
plugin=org.kde.panel
wallpaperplugin=org.kde.image

For Plasma to know which screen has which screen number it seems to need another configuration in .config/plasmashellrc. In my case:

[ScreenConnectors]
0=DP-3
1=HDMI-A-1

I achieve this with the following plasma-manager config:

plasma = {
      configFile = {
        "plasmashellrc"."ScreenConnectors" = {
          "0" = "DP-3";
          "1" = "HDMI-A-1";
        };
      };

      enable = true;     
      overrideConfig = true;
      overrideConfigFiles = [ "plasma-org.kde.plasma.desktop-appletsrc" ];
      panels = [{
        extraSettings = ''
          panels().forEach((p) => {

            /* set the screen number for the panel! */
            p.writeConfig("lastScreen", 0)

            /* I don't know if this is necessary,
                but without this, I got a random screen number for the systray as well */
            p.widgets().forEach((w) => {
              switch(w.type) {
                case "org.kde.plasma.systemtray":
                  systray = w.readConfig("SystrayContainmentId")
                  systray = desktopById(systray)
                  systray.writeConfig("lastScreen", 0)
              }
            })
          })
        '';

        widgets = [
          "org.kde.plasma.pager"
          {
            config = {
              General.launchers = [ ];
            };

            name = "org.kde.plasma.icontasks";
          }
          "org.kde.plasma.panelspacer"
          "org.kde.plasma.systemtray"
          "org.kde.plasma.digitalclock"
        ];
      }];
    };

Sidenote: I had a weird behaviour on plasma wayland session, where despite my script the screen numbers were randomly overwritten in plasma-org.kde.plasma.desktop-appletsrc. I started a X11 session once and since then it's also working in wayland.

[Svenum]

I will try tomorrow

[magnouvean]

I couldn't get that to work. The keys are just overwritten all the time here as well. Could it be that they just appear on the primary screen? This does look promising if we can get it to work reliably (and preferably without needing to log in/out two times). Another clever potential solution could be that since the panels appears on the currently focused screen, to just shift focus to the screen we want the panel to be placed on when generating the panels. The only problem with that approach is that I haven't found a way to actually focus on a certain input, but that should probably be possible in some way. I am not aware of any new capabilities in kde plasma 6 which makes this easier though, but I could have missed something.

[FF-AntiK]

Yeah, I figured under wayland I still have random lastScreen values.
But with X11 it's working so far.
Maybe the [ScreenConnectors] config is only working with X11, as I often read that it's somehow connected to xrandr which is a X11 tool...

[Svenum]

Ok, but I need this for Wayland sadly. But thanks for your help

[magnouvean]

I tested around with trying to move focus over to windows before creating panels as well, and while I did manage to create scripts for focusing different screens, it appears that the mouse must be on the screen for the panel to created on the monitor, and it does not look like moving the mouse to some screen is possible via the command-line on plasma wayland (it is probably possible on x11). Therefore I think we just will have to wait for kde to implement some kind of support for specifying monitor screen in plasma desktop-scripts. I might try to open an issue on some kde repo when I get time. This will probably take some time though as it would be in potentially some future release.

[Svenum]

Thank you for your effort. I will wait.

[FF-AntiK]

For now I get the best results by bypassing plasma-manager's panel option and just linking my plasma-org.kde.plasma.desktop-appletsrc into ~/.config via home-manager:

home.file.".config/plasma-org.kde.plasma.desktop-appletsrc".source =
  ./files/.config/plasma-org.kde.plasma.desktop-appletsrc;

The key for positioning the panel to a certain screen is still the lastScreen option I mentioned above.
This works also for my wayland session.

[magnouvean]

While not an ideal solution this does open up for the possibility of implementing this using plasma-manager directly as well. We could write the screen for a panel by adding panel.writeConfig("lastScreen[$i]", screen). Here [$i] will be needed in order for this to not be overwritten all the time. This like kwriteConfig does have the problem of [ and ] symbols not being supported, so we need to do some awk script or something to get it working properly (this should be easy). Then after making sure the configuration key/value is correct in plasma-org.kde.plasma.desktop-appletsrc we could kill the plasmashell process and start it again using kstart plasmashell. Luckily starting plasmashell doesn't seem to take much time so this shouldn't be much of a problem, but it does mean that the panels will first appear, disappear and then reappear. When not using overrideConfig this shouldn't need to be done that frequently though, and doesn't need to be done when we are not using specific screens, so it'll probably be fine. I have confirmed that this probably will work by doing some testing on my machine, but I have not tested if it will work from the autostart script. I'll test this approach when I get some more time in a few weeks, and if I am reasonably happy with how it works out this may be a good enough way of doing this until a better way is found on the kde side anyway.

[FF-AntiK]

I'm just asking out of curiosity. Is there a specific reason for using Plasma Desktop Scripting to generate the panels?
Why not generating the config files directly into the nix store and then linking it to ~/.config?

I still don't know much about how the internals of Plasma works, and maybe the problem is that Plasma expects the config files to be writable. But in my opinion (and I could be wrong), generating the config files directly would be much cleaner.

[magnouvean]

Having them writable is not the problem as the files plasma-manager generates are actually writeable. I do believe though that simply writing this file is not particularly simple as you have to deal with all sorts of ids and stuff which update all the time and is probably a pain to deal with. Maybe if we could use any id we want this would be possible, but I believe this is not straightforward (I might need to test this). Plasma scripts provide a quite simple way of dealing with all this in a higher level interface, though it does have some major limitations as I have found out.

[FF-AntiK]

I didn't run into any issues with hardcoded containment and applet (widget) ids so far.
For reference, this is my plasma-org.kde.plasma.desktop-appletsrc:

[Containments][1]
formfactor=0
immutability=1
lastScreen=0
location=0
plugin=org.kde.desktopcontainment
wallpaperplugin=org.kde.image

[Containments][1][Wallpaper][org.kde.image][General]
SlidePaths=/nix/store/wvvb3s3ham9i2rdi18hgxbkadjirggrq-breeze-qt5-5.27.10-bin/share/wallpapers/,/run/current-system/sw/share/wallpapers/

[Containments][2]
formfactor=0
immutability=1
lastScreen=1
location=0
plugin=org.kde.desktopcontainment
wallpaperplugin=org.kde.image

[Containments][2][Wallpaper][org.kde.image][General]
SlidePaths=/nix/store/wvvb3s3ham9i2rdi18hgxbkadjirggrq-breeze-qt5-5.27.10-bin/share/wallpapers/,/run/current-system/sw/share/wallpapers/

[Containments][100]
formfactor=3
immutability=1
lastScreen=0
location=6
plugin=org.kde.panel
wallpaperplugin=org.kde.image

[Containments][100][Applets][1000]
immutability=1
plugin=org.kde.plasma.pager

[Containments][100][Applets][1001]
immutability=1
plugin=org.kde.plasma.icontasks

[Containments][100][Applets][1001][Configuration][General]
launchers=

[Containments][100][Applets][1002]
immutability=1
plugin=org.kde.plasma.panelspacer

[Containments][100][Applets][1003]
immutability=1
plugin=org.kde.plasma.systemtray

[Containments][100][Applets][1003][Configuration]
SystrayContainmentId=110

[Containments][100][Applets][1004]
immutability=1
plugin=org.kde.plasma.digitalclock

[Containments][100][General]
AppletOrder=1000;1001;1002;1003;1004

[Containments][110]
formfactor=3
immutability=1
lastScreen=0
location=6
plugin=org.kde.plasma.private.systemtray
wallpaperplugin=org.kde.image

[Containments][110][Applets][1100]
immutability=1
plugin=org.kde.plasma.clipboard

[Containments][110][Applets][1101]
immutability=1
plugin=org.kde.plasma.notifications

[Containments][110][Applets][1102]
immutability=1
plugin=org.kde.plasma.devicenotifier

[Containments][110][Applets][1103]
immutability=1
plugin=org.kde.plasma.manage-inputmethod

[Containments][110][Applets][1104]
immutability=1
plugin=org.kde.plasma.pass

[Containments][110][Applets][1104][Shortcuts]
global=Meta+A

[Containments][110][Applets][1105]
immutability=1
plugin=org.kde.plasma.keyboardindicator

[Containments][110][Applets][1106]
immutability=1
plugin=org.kde.plasma.printmanager

[Containments][110][Applets][1107]
immutability=1
plugin=org.kde.plasma.volume

[Containments][110][Applets][1107][Configuration][General]
migrated=true

[Containments][110][Applets][1108]
immutability=1
plugin=org.kde.kscreen

[Containments][110][Applets][1109]
immutability=1
plugin=org.kde.plasma.keyboardlayout

[Containments][110][Applets][1110]
immutability=1
plugin=org.kde.plasma.nightcolorcontrol

[Containments][110][Applets][1111]
immutability=1
plugin=org.kde.plasma.battery

[Containments][110][Applets][1112]
immutability=1
plugin=org.kde.plasma.networkmanagement

[Containments][110][General]
extraItems=org.kde.plasma.clipboard,org.kde.plasma.notifications,org.kde.plasma.devicenotifier,org.kde.plasma.mediacontroller,org.kde.plasma.manage-inputmethod,org.kde.plasma.battery,org.kde.plasma.pass,org.kde.plasma.keyboardindicator,org.kde.plasma.nightcolorcontrol,org.kde.plasma.printmanager,org.kde.plasma.networkmanagement,org.kde.plasma.volume,org.kde.kscreen,org.kde.plasma.keyboardlayout
knownItems=org.kde.plasma.clipboard,org.kde.plasma.notifications,org.kde.plasma.devicenotifier,org.kde.plasma.mediacontroller,org.kde.plasma.manage-inputmethod,org.kde.plasma.battery,org.kde.plasma.pass,org.kde.plasma.keyboardindicator,org.kde.plasma.nightcolorcontrol,org.kde.plasma.printmanager,org.kde.plasma.networkmanagement,org.kde.plasma.volume,org.kde.kscreen,org.kde.plasma.keyboardlayout

As you can see, I even came up with my own numbering scheme, where 1,2 are the desktop containments for both of my screens, 100 is the panel, 110 is the system tray which is treated as a containment outside of the panel (because every panel uses the same systray, I guess), 10xx for widgets inside the panel and 11xx for widgets inside the systray.

[magnouvean]

Hmm, in that case we may have to test to see if this would be a better solution and if stuff works properly this way. That would potentially be both quicker and make us less dependent on plasma desktop scripting API which can be frustrating, though with that said it would need some testing as I can potentially see this adding some unexpected bugs with it (I would assume there is a reason why seemingly new ids are generated by plasma for these panels). Thanks for the input, I'll explore further when I have time :)

[FF-AntiK]

Thank you very much for the effort!
I wonder if there's a documentation of the Plasma configruation internals somewhere.
I already tried to find some hints in the code, but most of the time even finding the proper KDE project is just above my head, honestly ;-)

[Svenum]

Anyting new on this?

[magnouvean]

I'm gonna test some approaches and hopefully get something working next week. I haven't had much free time the last week to work on this project, but this is one of my biggest priorities when I do get time.

[cfitz25]

Ive been trying to implement panels being written to rc files on my fork if its any help (https://github.com/cfitz25/plasma-manager).
Currently it can grab and use panels from rs2nix, it also uses nesting for the nix options as it made dealing with the panels easier as they are quite nested.
Run nix run github:cfitz25/plasma-manager/trunk#demo-panels to see a test VM with a panels from rc2nix

[Svenum]

Seems fine for me, but I am not an nix expert. I am pretty overwhelm that you can run one command and get an qemu VM with nix installed in it...

[magnouvean]

I have tried to implement this without using desktop-scripts and while I did get it to work (with some bugs still), I also get that some of the previous panels will reappear even when I delete them from plasma-org.kde.plasma.desktop-appletsrc. This among other things makes me have some doubts about how well this solution will work tbh, and it does seem a bit too good to be true that the ids assigned by plasma bears no meaning at all. A.t.m. I think the best solution would be the somewhat hacky solution I proposed above and then change this implementation when we get more functionality in plasma scripts.

[magnouvean]

I have come up with this solution in #96, and can confirm it works quite well, but obviously not completely ideal. I think for now it is good enough. Feel free to try this out and see if it is good enough for you (keep in mind it uses the new config-format from #94 though, which essentially means that you need to add .value at the end of all the keys in configFile and such). If all is good I'll merge right after #94.

[Svenum]

@magnouvean sorry for the late response. This PR works great, but one problem:

error:
       … while checking flake output 'nixosConfigurations'

         at /nix/store/n8rl5zlqvbhzi7qq2zvklnc4wpiwlf53-source/flake.nix:9:5:

            8|   {
            9|     nixosConfigurations = {
             |     ^
           10|       Ni = lib.nixosSystem {

       … while checking the NixOS configuration 'nixosConfigurations.Shi'

         at /nix/store/n8rl5zlqvbhzi7qq2zvklnc4wpiwlf53-source/flake.nix:23:7:

           22|
           23|       Shi = lib.nixosSystem {
             |       ^
           24|         specialArgs = {

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: A definition for option `home-manager.users.sven.programs.plasma.configFile.khotkeysrc.Data.DataCount' is not of type `submodule'. Definition values:
       - In `/nix/store/4lkyp212hpwxi2l68q376j54rxgnhcwj-source/modules/hotkeys.nix': 

This should be related to #94. The Panel parts works as perfectly as expected. 👍

[magnouvean]

Yeah I think it is just a problem with the fact that #96 wasn't up to date with trunk. I have merged the newest commits now. Does it work now?

[Svenum]

Yes now its working fine

[magnouvean]

Great! I will probably merge it tomorrow. Regarding writing manually to the file I still think it may be worth looking into if anyone is willing to experiment with this and think it is possible to get it working well (though I have a bit limited time with exactly this problem). For it to be viable though I would like such a solution to have as good support for the various options as the current plasma-scripts solution, as well as the fact that it should be able to work even if the user has existing panels. It also needs to be quite bug-free of course. If all this can be achieved I would welcome using this solution, but until this can potentially be achieved I reckon the solution in #96 is good enough, even if it is a little bit hacky.