* Mutter signal order ** When window A is closed 1. The next window, B, receives 'focus' (but the actor of A seems to be gone?) 2. Workspace receives 'window-removed'. ('A' seems to have been stripped of signal handlers) ** When window A is created 1. on workspace "window-added" is run, actor isn't available 2. on display "window-created is run, actor is available 3. focus is run if the new window should be focused * Keybinding system Action names are global. eg. `Meta.keybindings_set_custom_handler` works on keybindings from custom schemas too. (despise what the documentation says) `[[https://developer.gnome.org/meta/stable/MetaDisplay.html#meta-display-add-keybinding][MetaDisplay.add_keybinding]]` (somewhat confusing name) is used to register a named keybindable action. An numeric id is returned. Keybinding handlers fire on key-down. Mutter itself does not support key-release sensitive bindings, but it's possible to create a Clutter actor in response to a key-down binding, which temporarily take over the keyboard. Clutter can listen for key-up/key-release events. Looking up which action a key is bound to return the action's numeric id (`[[https://developer.gnome.org/meta/stable/MetaDisplay.html#meta-display-get-keybinding-action][MetaDisplay.get_keybinding_action]]`). There is no(?) way to ask mutter for the id<->action-name mapping. It's not possible to look up the handler of a keybinding action...(?) A slightly annoying detail about how all this works is that you normally give the handler before you know the action-id. So if the handler need to know the action-id (eg. if it use clutter to implement a mini-mode and want to respond to the same key that triggered the mode) you either have to store a name->id map, or re-assign the handler afterward. The Keybinding object which is supplied to keyhandler doesn't seem to expose the key used to trigger the action either? ** Modifier-only bindings Simply use the keysym name as if the modifier was a regular key. Don't use angle brackets - those are used for **modifiers**. : settings.set_strv("my-action", ["Super_L"]) ** Bind keys without using actions from a schema https://stackoverflow.com/a/42466781/1517969 * Stack level There's not enough room for a maximized window to slide above another maximized window if they move at the same speed: #+BEGIN_SRC front window A -> | ---------------- | window B | ----|----------- select window B front -----------|---- | window A window B -> | ---------------- | #+END_SRC * GJS ** import system `imports.NAME` reflects the directories and javascript files present in `imports.searchPath`. To add a path, simply do `imports.searchPath.push(PATH)` The entries can also(?) be special uri's referring to directories with .gir files(?) Or maybe more likely: `imports.gi.` contains everything that's exposed through .gir files. `GJS_PATH` might be used too. ** Debugging *** Get a stacktrace `(new Error()).stack` * GObject The `notify` signal is emited on changes to all GObject properties. Listen to `notify::propery-name` to only receive for changes to ` property-name`. ([[https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#GObject-notify][Reference]]) * TODO Firefox focus bug Sometimes firefox windows refuse to gain proper focus. What happens is that another (or multiple!) firefox window somehow have focus in the address bar. The workaround is to find that/those window(s) and remove focus from the address bar. Not sure if firefox, gnome-shell, or our js code is at fault (although I suspect the altTab.js extended code) * DONE PreviewedWindowNavigator bug CLOSED: [2017-09-21 to. 23:35] Sometimes ensures the starting window instead of the selected window, while focus is correctly set. Not sure how to reproduce. * DONE Generalize to work with more workspaces CLOSED: [2017-09-14 to. 00:28] Partially fixed with workspaces[i][j] * DONE Move initial positioning into actor's first-frame signal CLOSED: [2017-09-14 to. 11:16] Don't scale new windows The actor's ~first-frame~ signal is probably the place to do this: [[https://developer.gnome.org/meta/stable/MetaWindowActor.html#MetaWindowActor--meta-window][MetaDisplay::window-created is a good place to connect to this signal - at that point, the MetaWindowActor for the window exists, but the window has reliably not yet been drawn. Connecting to an existing window that has already been drawn to the screen is not useful.]] * TODO Hook up resize/move functionality * TODO More keybindings, eg. meta- * DONE(*) Window search `rofi -show window` is decent off-the-shelf replacement. * DONE Scaling bug CLOSED: [2017-09-21 to. 23:35] Possible fix: hide the actual window and replace it with a clone, which only sets focus on click * TODO General animation consistency * TODO Better alt-tab * DONE Detect transient windows 42d272bea11b7c29965a201ec45ed3ca3a85ea81 * Regression: add_handler doesn't handle the first window * Move behavior Integrate mouse move and keyboard move. Pop the window out and on top of the other windows, leaving a scaled down gap, when initiating move (either with the mouse or `begin-move`). See [[move.png]]. Cycling through windows should then move the active window around. Moving with the mouse should move the gap around appropriately, possibly scrolling the strip (though that might be confusing). * Crash bug Replicate by opening and closing eg. copyq very fast, it seems there's a threshold which always triggers a crash. ``` sep. 11 18:45:01 x230 org.gnome.Shell.desktop[26137]: focus: gnome-shell-minimap: tiling.js | emacs [ x:-526, y:29 w:1220 h:737 ] sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: window-added [object instance proxy GType:MetaWindowX11 jsobj@0x7faea590b370 native@0x25fb7d0] display - CopyQ 0 sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: focus: display - CopyQ [ x:0, y:27 w:662 h:737 ] sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: setting initial position [object Object] sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: focus: debug [ x:1230, y:29 w:642 h:737 ] sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: window-removed [object instance proxy GType:MetaWindowX11 jsobj@0x7faea590b370 native@0x25fb7d0] display - CopyQ sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: focus: gnome-shell-minimap: tiling.js | emacs [ x:0, y:29 w:1220 h:737 ] sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: ** sep. 11 18:46:17 x230 org.gnome.Shell.desktop[26137]: mutter:ERROR:core/window.c:5041:meta_window_get_workspaces: code should not be reached sep. 11 18:46:20 x230 org.gnome.Shell.desktop[26741]: current session already has an ibus-daemon. ``` 1. window-removed on copyq 2. focus on the last window 3. crash 4. On restart a copyq window is still there suggesting that it was either not removed properly, or started to run just before the crash