6.9 KiB
- Mutter signal order
- Keybinding system
- Stack level
- GJS
- GObject
- Firefox focus bug
- PreviewedWindowNavigator bug
- Generalize to work with more workspaces
- Move initial positioning into actor's first-frame signal
- Hook up resize/move functionality
- More keybindings, eg. meta-<number>
- DONE(*) Window search
- Scaling bug
- General animation consistency
- Better alt-tab
- Detect transient windows
- Regression: add_handler doesn't handle the first window
- Move behavior
- Crash bug
Mutter signal order
When window A is closed
- The next window, B, receives 'focus' (but the actor of A seems to be gone?)
- Workspace receives 'window-removed'. ('A' seems to have been stripped of signal handlers)
When window A is created
- on workspace "window-added" is run, actor isn't available
- on display "window-created is run, actor is available
- 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)
`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 (`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
Stack level
There's not enough room for a maximized window to slide above another maximized window if they move at the same speed:
front
window A -> | ---------------- |
window B | ----|-----------
select window B
front
-----------|---- | window A
window B -> | ---------------- |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`. (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:
TODO Hook up resize/move functionality
TODO More keybindings, eg. meta-<number>
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
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 
.
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. ```
- window-removed on copyq
- focus on the last window
- crash
- On restart a copyq window is still there suggesting that it was either not removed properly, or started to run just before the crash