Global Config Open: Tab does not switch when it's already open

[deeplow]

Qubes OS release

Qubes OS 4.3

Brief summary

https://github.com/QubesOS/qubes-issues/issues/9530 introduced the ability to switch to the Global Config tab. However, I don't think it assumed the possibility of Global Config already being opened. In that case, it simply does not switch tab.

Steps to reproduce

Alternative 1:

1. Open Qubes Global Config (should be on "General")
2. Devices tray widget » [choose device] » auto-attach settings

Alternative 2:

1. Open Qubes Global Config
2. Qubes Template Manager » ⚙️ Repository Settings

Expected behavior

1. If already open, Global Config window becomes focused
2. Correct tab is selected Alternative 1: Switches Qubes global config to "Device Assignments" tab. Alternative 2: Switches Qubes global config to "Updates" tab.
3. In case something had not been saved, prompt the user to save it (this behavior is already present which manually switching tabs amidst pending changes).

Actual behavior

• Doesn't switch to the right tab.
• Global config Window is not focused: in the alternative 2 this is more clear: the template manager looks visibly frozen with the ⚙️ Repository Settings pressed, without apparent way to unfreeze it (actually, one needs to close the Global Settings to unfreeze it, but this is not apparent since the user did not see a causal relationship with the Global Config window).

Additional information

This is probably an annoying bug that will scope-creep the "open in tab" logic (which was just 1 line for the call and pretty simple on the implementation).

Solution ideas:

• messing with DBus for IPC
• (and idk if this is possible), but it could be to use the GTK "application is already open" logic to send a signal to the existing running instance to open at the right tab.
• killing a running instance of global config and opening it again at the right tab

[marmarta]

This is not a great program to be running in the background, I think it should just not be able to be opened when it's already open.

[deeplow]

This is not a great program to be running in the background

Do you mean this in the sense that it's heavy on the system? Or that it's hard to work with to make these sort of nuances?

I have now added another example, where Template Manger looks frozen. In this case, it's less clear to the user what happened.

Solution ideas: [...] - killing a running instance of global config and opening it again at the right tab

I have now added a third solution idea. It might be the easiest to implement, if this is considered a bug worth solving. In the case something was amidst editing, I believe Global Config would already prompt the user to save the pending changes.

[marmarta]

Do you mean this in the sense that it's heavy on the system? Or that it's hard to work with to make these sort of nuances?

Mostly that it does not react to changes of system state and so if it's left alone running for a long time or in multiple instances, it could get desynced from system state. I don't like the idea to kill it and re-open, I think the best solution would be to fail to open it, I think.

The Template Manager thing does need a solution, I think it should show a message "save your config changes" or something to this effect while editing the settings...

[deeplow]

Do you mean this in the sense that it's heavy on the system? Or that it's hard to work with to make these sort of nuances?

Mostly that it does not react to changes of system state and so if it's left alone running for a long time or in multiple instances, it could get desynced from system state. I don't like the idea to kill it and re-open, I think the best solution would be to fail to open it, I think.

Yes, I don't like it either.