PaperWM/notes.org

• Mutter signal order
  • When window A is closed
  • When window A is created
• Keybinding system
• Make a proper github repo
• Stack level
• GJS
  • import system
• Firefox focus bug
• PreviewedWindowNavigator bug
• Make all keybindings work when Super is depressed
  • While extending the builtin switcherpopups
  • Do our own thing
• 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>
• Simple scratchpad
• DONE(*) Window search
• Scaling bug
• General animation consistency
• Better alt-tab
• Detect transient windows
• WIP Don't focus window until modifier release
  • Next/previous window in tiling
• Persist window order across gnome-shell restarts
• Regression: add_handler doesn't handle the first window
• Move behavior
• Crash bug

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 is global. eg. `Meta.keybindings_set_custom_handler` works on keybindings from custom schemas too.

Bind keys without using actions from a schema: https://stackoverflow.com/a/42466781/1517969

TODO Make a proper github repo

Lets call it PaperWM for now, or perhaps PaperGnome / GnomePaper if we want it to be more connected to the gnome name, (probably not though).

Put it under ScrollWM or just make a new user?

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.

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)

TODO PreviewedWindowNavigator bug

Sometimes ensures the starting window instead of the selected window, while focus is correctly set. Not sure how to reproduce.

TODO Make all keybindings work when Super is depressed

NB: Should work in conjunction with "focus-change-committed-on-modifier-release".

While extending the builtin switcherpopups

The altTab.js/switcherPopup.js "modes" use `Main.pushModal` (–> `shell_global_begin_modal`) which grabs all keys by default. Seems to be overridable (at least if we override the `show` method (which calls pushModal)), but my guess is that the various popups don't pick up changes in the window list for instance.

Might be possible to test the effect adhoc by messing with `Meta.actionMode`?

Do our own thing

Suggestion: Create a listen-for-key-release hidden actor on all keybindings and use that to mark a navigate-mode. Ideally normal focus changing operations would be captured when in this mode and prevented from taking effect until naviagate-end, so existing code would work without modification. Not sure that simple to achieve though.

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:

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-<number>

TODO Simple scratchpad

Probably easiest/best to

DONE(*) Window search

`rofi -show window` is decent off-the-shelf replacement.

TODO Scaling bug

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

42d272bea1

WIP Don't focus window until modifier release

We probably want this behavior for all window navigation functions.

Note: The mutter keybinding system only doesn't expose keyrelease events. But it's possible to create a clutter actor in response to a mutter keybinding and listen to keyup/keyrelease there.

Next/previous window in tiling

Preliminary implementation based on the extending classes from altTab.js. Currently based on WindowCyclerPopup since that most closely matched the behavior from notion/paper-wm: Simply move to next/previous window scrolling the tiling along.

Could also use WindowSwitcherPopup which show a preview strip of the windows. Doesn't move to the window by default, but that is likely to be simple to change if wanted.

TODO Persist window order across gnome-shell restarts

Since the xid's don't change a simple xid -> window-placement map regularly written to disk should suffice.

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. ```

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