Thomas Fini Hansen

I've been digging around to see if I could fix it myself, which I haven't quite, but I'll add my findings here. I've realized why the current implementation is moving...

Well, I got somthing somewhat working here: https://github.com/xendk/material-shell/commit/bd3cfd1107659319cb89223ba6d8028bb34532f6 But apparently `global.display.get_focus_window()` returns null when the app launcher is active (not a real window I suppose), which kills next/prev window as...

So, been running with this all day, and apart from the mentioned app launcher thing, the only other thing I've noticed is that new windows get added in the workspace...

Ah, an Actor. I'm not very familiar with the workings of Gnome or the API, so I'm just fumbling along. So, I'll should be able to find the msWorkspace with...

> It's depend what you mean by "decide" Well, I was thinking whether it was the workspace under the pointer or the one containing the focused window/actor.. But maybe that's...

I must admit though, there is an inconsistency in click-to-focus in Gnome: Mouse wheel *always* scroll the window under the pointer, not the focused one. But I still think that...

> But I'm not sure where No, it's a tad difficult to figure out without some more multi-monitor users weighing in. A couple of points though: The existing "focus monitor"...

I've been running with https://github.com/xendk/material-shell/commit/bd3cfd1107659319cb89223ba6d8028bb34532f6 for some time, and It Works For Me™. It could deal better with actors, but it hasn't irritated me enough. It basically just makes the...

> But on pop shell when you change window through keybinding it moves the cursor to the top left corner of the window. I don't like that, but I'd better...

Indeed. It could be an option, but then the easiest way to implement it would still be by fixing keyboard focusing and implement mouse-follows-focus on top of that. Maybe it's...