Add option to move cursor only when window is on different display.

[MeanEYE]

First of all, thank you so much for this extension. This is something I wanted to make myself but never found the time to actually go and do it.

As the title says, it would be great if we had option to only move cursor when focus is changed to window located on different display. Currently cursor will move on every focus change, with this option turned on cursor will move only when focus is switched to window on different display.

This behavior is useful in cases where people have many different displays but want cursor to move on focus change only when focusing window on a different display instead of moving mouse manually.

[buzztaiki]

Well, it looks good for some people.

Maybe, we can use window#get_monitor() for this purpose. I'll try to implement it.

(But I don't think I'll be using this feature in the near future for me, so I'm sorry if it doesn't get implemented.).

[buzztaiki]

If you have a time, PR would be welcome!

[MeanEYE]

If you have a time, PR would be welcome!

I will try to find some time but I make no promises, work is killing me these days.

Is the focus event before new window is focused or after?

[buzztaiki]

work is killing me these days.

😢

Is the focus event before new window is focused or after?

Uh, actually, this extension is implemented in an ad-hoc way, not by subscribing to events, but by monkey-patching the _finish method of SwitcherPopup.

gnome-shell-extension-alt-tab-move-mouse/extension.js

Lines 30 to 33 in f44cb43

	SwitcherPopup.prototype._finish = function () {
	that.move_pointer_maybe();
	that.orig_method.apply(this, arguments);
	};

Normaly, SwitcherPopup#_finish is called after the window is focused.

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/altTab.js#L269-277

    _finish(timestamp) {
        let appIcon = this._items[this._selectedIndex];
        if (this._currentWindow < 0)
            appIcon.app.activate_window(appIcon.cachedWindows[0], timestamp);
        else if (appIcon.cachedWindows[this._currentWindow])
            Main.activateWindow(appIcon.cachedWindows[this._currentWindow], timestamp);

        super._finish(timestamp);
    }

gnome-shell-extension-alt-tab-move-mouse/extension.js

Line 41 in f44cb43

const window = global.display.focus_window;

[MeanEYE]

That then means if the application presents itself with focus or present nothing will happen? Since switcher wasn't activated in the first place. These case are not as frequent though, but they do exist.

[buzztaiki]

That then means if the application presents itself with focus or present nothing will happen? Since switcher wasn't activated in the first place. These case are not as frequent though, but they do exist.

Yes. That's correct. For example, if you launch an application from the Dock, the mouse cursor will not move over the application with this extension.

I really wanted a way to handle focus events, but I couldn't find one, so I implemented it this way.

[MeanEYE]

I think I remember running into window focused event example code some time ago, but I can't seem to find it now.

Even though you are monkey patching the switcher, it should still be possible to grab previous/current window by implementing simple stack of sorts, where on every focus event we'd push new window id in the stack. Condition then would be if the displays between last two windows differ then focus.

Of course this would also have to include some sort of configuration window so users can turn off this functionality if they don't like it.

[buzztaiki]

Even though you are monkey patching the switcher, it should still be possible to grab previous/current window by implementing simple stack of sorts, where on every focus event we'd push new window id in the stack. Condition then would be if the displays between last two windows differ then focus.

Sorry, I'm a little confused. Maybe it's because my English is not good enough.
Are you trying to explain how to get all the focus events with monkey patching on the switcher?

[MeanEYE]

I was explaining how what I wanted to achieve can be done with your current approach. A bit hacky, but it should work. Basically looking from your reply whether this approach is acceptable by you.

[buzztaiki]

Even though you are monkey patching the switcher, it should still be possible to grab previous/current window by implementing simple stack of sorts, where on every focus event we'd push new window id in the stack. Condition then would be if the displays between last two windows differ then focus.

I see. Your implementation is acceptable. I don't mind that it's hacky. The original implementation is already hacky :)

However, I think, your purpose could be achieved by simply comparing the results of Display#get_current_monitor and Window#get_monitor.

What do you think?

[MeanEYE]

Hm, yes. That's even shorter. So the biggest challenge now is creating configuration window and storing that data in DConf ili GConf, whatever they are using these days.

[buzztaiki]

Yah, I think so settings of extension is pretty hard. I've never written anything practical either.
You may already know this, but the following may be helpful:

• https://wiki.gnome.org/Attic/GnomeShell/Extensions/Writing#Extension_Preferences
• https://gjs.guide/extensions/development/preferences.html#creating-the-schema

I've also written a simple example of schema handling in the past, which you can refer to here if you want (although there is no configuration window):

• https://github.com/buzztaiki/gnome-shell-extension-keybinding-example

[MeanEYE]

Am contemplating whether having this whole configuration window is even needed for a single option. It sounds like an overkill. Simple JSON configuration file which is read on extension load might be the easiest approach until there's more complex configuration to be had. Adding configuration window, schemas and whatnot just for slight alteration in behavior... doesn't sound right.

[buzztaiki]

Yeah, I don't think the configuration window is necessary for now.

It is better to use a schema for the configuration file, but you can implement it the easy way first, and I will change it to use a schema after I receive the PR.

[MeanEYE]

Okay, great. I'll try to make this in next few days. No promises though since I am preparing release of new version for my file manager. That one is 2 years overdue. :)