extensions: "enabled" can be ambiguous
The "enable(d)" term is used with two subtly different meaning:
- request an extension to be enabled
- the extension's
enable()
method was called and didn't throw an error
Usually the two are largely synonymous: 1. changes the underlying GSettings, then 2. happens.
There are two exceptions:
- when the extension has an error, its still set-to-be-enabled (on relogin), but the state changes to
ERROR
- when an extension only targets the lock screen: its set-to-be-enabled in the user session, but the state will only change to
ENABLED
on screen lock
This isn't an issue as far as extensions are concerned, but it affects tooling: The Extensions app uses the ENABLED
state for the switch state, which means that an extensions that is set-to-be-enabled but not enabled cannot be turned off (the current state is DISABLED
, so changing the switch tries to enable the extension, but it's already enable according to GSettings).
That is, I think it would be beneficial for tooling to have a separate boolean property that reflects whether or not an extension should be enabled according to settings.
What I'm not sure about is naming. Off-hand enabled
makes the most sense to me, but it clashes with the ENABLED
extension state. Although we could rename the latter to (DE)ACTIVATED
? It wouldn't affect the D-Bus API, where the state is of type d
. Another option could be requested
, but what would the counterpart of that be?
Thoughts?
@firox263, this is likely interesting for extension-manager as well.