dconf variables not reset at uninstall/disable of extension

[Scafir]

Describe the bug
When the extension is disabled or uninstalled, the dconf variables set in https://github.com/Leleat/Tiling-Assistant/blob/main/tiling-assistant%40leleat-on-github/schemas/org.gnome.shell.extensions.tiling-assistant.gschema.xml are never reset to their original value. This causes (probably among other things):

• No edge tiling
• No window movement on super+arrow keys

Steps To Reproduce

1. Install the extension
2. Disable (or uninstall) the extension

System Info:

• Distro (incl. version): Fedora Linux 39 (Workstation Edition)
• GNOME Shell version: 45
• Extension version and from where: 45 (but same on 44), EGO
• XOrg/Wayland:

Journalctl logs
Not relevant

[Leleat]

When the extension is disabled or uninstalled, the dconf variables set in https://github.com/Leleat/Tiling-Assistant/blob/main/tiling-assistant%40leleat-on-github/schemas/org.gnome.shell.extensions.tiling-assistant.gschema.xml are never reset to their original value. This causes (probably among other things):

You are mixing up 2 issues there.

1.)

The settings of Tiling Assistant not resetting on disable/uninstall is intended behavior. I guess you can argue for a reset when uninstalling an extension but if you do, that shouldn't be an extension by extension decision. It should be done by the extension system itself (i. e. GNOME Shell).

2.)

When Tiling Assistant gets disabled, GNOME's native settings (e. g. edge tiling or the keyboard shortcuts) are restored to the value they had when the extension got enabled (see #244 for more info).

You can simply test it by disabling/uninstalling the extension, enabling Active Screen Edges (edge tiling) in GNOME Settings under Multitasking, and then toggling Tiling Assistant again. You will see that Active Screen Edges will toggle along with it.

If in the past, GNOME's native settings didn't get restored as you would expect, that means that Tiling Assistant saved unexpected value when it got enabled. There a few possible reasons for that:

a) another extension overrode the same setting as well which led to Tiling Assistant saving a bad state, or
b) you've used an older version of Tiling Assistant (without #244) that didn't cover the cases of #244, which led to a 'bad state' of GNOME's native settings being saved.

Either way, there is nothing for me to fix.

At this point b) can only fixed by the user by: 1. Disabling Tiling Assistant 2. Then setting all native GNOME settings to whatever value they want Tiling Assistant to restore the values to after a disable and 3. re-enabling Tiling Assistant.

That still leaves a). That is not something I can fix since Tiling Assistant and any other extension aren't 'aware of what other extensions are doing'. That case should also probably be handled by GNOME Shell itself.

[Scafir]

Hey,
Thank you for the very complete answer, I appreciate it.
Strangely enough, even tough I uninstalled/reinstalled to make sure that it wasn't a fluke before submitting the issue, I am now unable to reproduce the original issue.. I guess I either messed up, or some sort of "flushing" made by the uninstall of the newer version was required before things started working again.
In any case, thank you for your work!

[fthx]

Hi,

I tried this extension (Ubuntu 25.04 dev) recently.
And it erased (= no shortcut) Windows+ actions.
To be clear, shortcuts not restored to initial state after disabling the extension.
No other extension installed does hack the GS shortcuts.

[Leleat]

No other extension installed does hack the GS shortcuts.

There are quite a few extension that take over shortcuts (and other settings) from GNOME and it makes sense for a tiling extension to take over the tiling-related shortcuts. Otherwise, the shortcuts would be very obscure since GNOME pretty much already sets all Super + [other_mod +] direction. To name a few other popular examples that override existing shortcuts: PaperWM, pop-shell, Tiling Shell.

Of course, Tiling Assistant should restore the shortcuts (and other overridden settings) when it gets disabled. And Tiling Assistant does that... with the caveats mentioned in my previous comment above:

Screencast.From.2025-01-19.19-24-13.mp4

I tried this extension (Ubuntu 25.04 dev) recently.

Tiling Assistant doesn't support GNOME 48 yet. I hopefully can port the extension in the next few weeks and take a look if the settings restoration is broken there. If you have this issue on GNOME 47, please open a new issue. Please keep the caveats mentioned in my previous comment in mind.

[fthx]

That's not what I meant: none of my installed extensions does hack the shortcuts. Obviously I understand why it's necessary here.

And the settings were not restored to the GS defaults, they were set to none.
Plucky uses GS 47 at the moment.

[Leleat]

And the settings were not restored to the GS defaults, they were set to none.
Plucky uses GS 47 at the moment.

Hmm, okay, I am on Fedora and it works here. I'll take a look at Ubuntu,

[Leleat]

And the settings were not restored to the GS defaults, they were set to none.
Plucky uses GS 47 at the moment.

[Leleat]

And the settings were not restored to the GS defaults, they were set to none.
Plucky uses GS 47 at the moment.

Uhh, pressed enter too early... any way.

I had some time now and took a look at this. I wasn't able to see the issue. Tiling Assistant restores the settings value to whatever value it was when it was enabled (not GNOME'S default). This seems to work as intended. Here is a screencast:

Screencast.From.2025-02-10.16-32-11.mp4

The only thing I can imagine happening here is that for whatever reason, your shortcuts were already disabled before Tiling Assistant was enabled, so Tiling Assistant saved the disabled state and restored it afterwards. But that is pure speculation and maybe there is an actual bug here. But I would need clear steps to reproduce the bug, so that I can investigate it.

[fthx]

Unfortunately, I do not use Tiling assistant.
So that's hard to do better for me.