search

khimaros / smart-auto-move

Smart Auto Move learns the size and position of your application windows and restores them to the correct place on subsequent launches. Supports Wayland.
https://extensions.gnome.org/extension/4736/smart-auto-move/
GNU General Public License v3.0
79 stars 4 forks source link

re-evaluate switch from event based operation #28

Open ZimbiX opened 2 years ago

ZimbiX commented 2 years ago

There is a slight delay where the window is its initial size/position before Smart Auto Move changes it. This applies to non-maximised windows (it seems that Gnome remembers the maximised state by itself; so that's fast). In coming from Maxi, I was expecting the resize to be quicker.

I can see that this extension uses polling, from playing with the 'sync frequency' setting (when setting this to 5000ms, there can be a few seconds before a new window is resized), and looking at the source. I tried reducing the polling interval from the default of 100ms, but it has a minimum of 50ms, which does not eliminate the stutter. At that polling rate, the CPU use of gnome-shell is ~10% higher than with the extension disabled, which is not great.

Would it be possible to switch over to being event-based? Maxi is event-based, but that only has to listen for window creation, not also having to deal with saving window sizes; but perhaps there are resize/maximise/unmaximise events?

Thanks for making this extension =)

ZimbiX commented 2 years ago

I think I found the docs for the necessary signals:

khimaros commented 2 years ago

thank you for the suggestion, @ZimbiX

the first implementation of smart-auto-move actually used this strategy. you can see the change that started to move away from signal based window management here: https://github.com/khimaros/smart-auto-move/commit/00c189e053c4c6ac48a77025fcb23ca89569fb2a

there are limitations with the shell extension framework that made it problematic. in particular, if you change the properties of a window inside of an event instead of in the mainloop, they do not hold.

from the original documentation: "changing a window's frame rect inside of [the windows-changed] handler does not actually move the window, so it instead needs to happen in the Mainloop." -- which also required an arbitrary timeout.

managing this inconsistency resulted in some race conditions and technical debt, so i switched to the polling method.

ZimbiX commented 2 years ago

Interesting. Thanks for the context!

It looks like Maxi waits on a subsequent event, focus before maximising - would that help? Or does maximising not have the same restrictions as resizing?

On the saving side of things, was there a reason that needed to use polling too?

khimaros commented 1 year ago

switching to an event based mechanism would most likely help with issues like the one mentioned in https://github.com/khimaros/smart-auto-move/issues/31