Needed due to weird hang (sometimes crash) when creating (probably only when
done rapidly?) same relocatable setting more than once.
(noticed when implementing workspace settings cycling)
Defaults to true. If false uses gnome shell's `Activities` text and hides the
workspace labels.
Set to false like this:
```
Extension.imports.convenience.getSettings()
.set_boolean('use-workspace-name', false)
```
X11: A regular intermediate window is created before the actual prefs dialog.
This cause trouble - it's inserted shortly into the tiling.
Wayland: The prefs dialog is opened as a regular window
We'd like the prefs dialog (at least our own) to float.
Not exposed in the preference ui yet.
Can be set with dconf or in `user.js` like this:
var settings = Extension.imports.convenience.getSettings();
settings.set_string('default-background', '/path/to/image.jpg');
ref #83
This is the common functions needed for both the extension side and prefence UI
side, so it goes in `settings.js`.
`Settings.findConflicts` searches for keycombo conflicts between our own
bindings and the built in Gnome Shell and mutter bindings, returning an array
like this:
```
[{ name: our own action name,
conflicts: array of conflicting names
settings: the settings schema the conflicting are part of
combo: the key combo as generated by keystrToKeycombo},
...]
```
keystrToKeycombo now handles `Above_Tab` properly.
Per workspace settings can be accessed through `space.settings`.
A setting's path is stored under its uuid in
`/org/gnome/shell/extensions/paperwm/workspaces/${uuid}/`. When modifying a
workspace setting the uuid will be recorded in
`org.gnome.Shell.Extensions.PaperWM.WorkspaceList`.
Spaces get their settings by looking for an uuid with an `index` key
corrosponding to its `workspace.index()`. If such a setting can't be found the
space will be given a fresh uuid and the name and color will be assigned as
before.
Ole Jørgen Brønner