Multiscreen only updates one widget

[JurgenCruz]

I have a 3 monitor setup with the panels and task bars. If I use the widget in screen one to update the system, that widget no longer shows updates, but the widgets in the other screens still show updates until I manually click and search updates from the other instance of the widget.

Also, I had an instance where I configured the widget but then the configuration wizard came up again and ask me to configure again. At the moment I thought it was just a glitch but now I'm wondering if it was asking me to configure the two separate instances for each screen. I'm not sure on this last one, just an FYI. Also, I don't use virtual desktops, but it could also be a problem there, not only for multiple monitors, but multiple desktops.

Thanks!

[dhruv8sh]

I see. Virtual desktops don't have this issue. On multiple screens, Plasma assumes the same widgets on two different screens as two different instances. This can be solved by keeping track of a local cache. Currently, there is no caching implemented by the applet and is planned for a later date. I will notify you when it is.

[dhruv8sh]

This feature will not be implemented due to the following reasons:

• Each instance follows their own configurations. Meaning, you could enable and disable AUR Wrappers on two different instances, respectively. If they all are synced, it becomes impossible to keep a track of what's what.
• Caching these files is one extra step the widget has to follow. Making the applet appear slow and bloated. This especially would affect people with low-end systems with low IO disk speeds.
• I would have to implement a synchronous system just so these instances don't write the same file at once, garbling the data. Making the applet even slower and heavier on resources.

What you can do is, enable the applet inside only one tray, or only enable notifications for one if using more than one instances.

[JurgenCruz]

Hi,

From your points above:

1. What is the use case of having one screen with AUR wrappers enabled, and another screen having AUR wrappers disabled? I have the exact configuration in all 3 instances, and I had to manually copy the configuration for all 3.
2. Not sure why caching will make it slow and bloated if today it already needs 3 files for 3 screens to keep the config separated. Can't this be solved by using a singleton that reads a single config file for all instances?
3. If the above singleton is shared across the instances then you don't need to worry about the instances writing the file at once. I don't see a race condition happening, you would need to open the config screen of 2 instances at the same time and clicking "Save" fast enough in both dialogs for a write race condition to happen.

Sharing the data should make it more efficient and less bloated, not consume more resources.

I'm looking at it from this perspective: If I have discord open and I get a message, a red dot appears in the tray for all trays. If I read it, all the trays are updated and the read dot disappears. if I click any of them, it will open/focus the discord window.

Or take the KDE clipboard tray icon, whichever icon I click, shows me the clipboard and can clear it. If I clear the clipboard in one tray, it clears it in all trays. It is expected that there is a single process owning the data, and the 3 icons in the trays just communicate with this process.

BTW, if I click the settings button in the clipboard widget it will open a single dialog for all 3 instances. it will not open a second dialog. the settings are shared.

[dhruv8sh]

• The example you give of the clipboard manager is invalid here. The applet is just a mere front-end for the service running in the background. Also, there are no configs to not be shared here, hence the data can be shared. I will have to make another service just for this to work by this logic, where this is no more an applet.
• Plasma applets are not able to share states/configs amongst themselves as far as I know. You have the same config for these instances, other people might not. Making it really difficult/impossible to read caches without keep track of a cache for each file.
• The race condition I'm talking about is while the applet writes to the cache file. It is a part of the applet itself. They would try to write to the same file at the same time on boot. I am aware there are some clever workarounds for this, but I feel like its, not worth it.

You are approaching the issue as if this project is an app. Here's an idea to solve it. Write configs into a file instead, read from it for all of them. But then I would have to design all the config pages and commands to match it (again). Are you willing to help with that if you really want it?

[JurgenCruz]

I understand. The scope of the project was not meant to be an app, just a widget and the limitations of the widget system prevent such use cases. Even if you shared the config file, like you mention, the cache would be a problem. So I'm fine with closing this issue. I guess I can just lower the refresh time so the icons refresh faster and they sync naturally.