Deja Window is a GNOME Shell extension that gives you full control over your window geometry. It automatically restores the workspace, size, position, minimized and maximized state, always on top and always on visible workspace of specific applications when they open. 🤔 Why Deja Window? In "vanilla" GNOME, windows typically open in the current workspace either centered or in a upper-left layout. Deja Window bridges this gap by acting as an external memory for your window layout, forcing the desired position, size and states that the OS or the apps themselves cannot natively restore. Deja Window is also very useful for all those applications (such as Ghostty) that do not adequately manage the layout of their windows in Gnome. 🚀 Features - Remembers the last known position, size (included workspace) and states (minimized and maximized, always on top and always on visible workspace) of your windows. - Configure specific rules per window (via WM_CLASS or Window Title). - Supports standard string matching and regular expressions (Regex) for advanced targeting. - Choose to restore workspace, size, position, minimized and maximized state, always on top and always on visible workspace, independently for each app. - Automatically centers windows that are configured but haven't been saved yet. - Handles the specific timing constraints of window management on Wayland. Compatibility Note: While this extension works with the majority of standard applications, some apps utilize custom layout mechanisms or non-standard toolkits that may override or ignore the extension's positioning attempts. More troubleshooting info can be found in the README.md file on GitHub.
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 9 | Active |
| 8 | Rejected |
| 7 | Active |
| 6 | Rejected |
| 5 | Rejected |
| 4 | Inactive |
| 3 | Rejected |
| 2 | Inactive |
| 1 | Rejected |
Refactored the window management logic to improve reliability and performance across both Wayland and X11 sessions. Key Changes: - Replaced arbitrary timeout_add delays with a robust event listener on the window actor (notify::mapped). This ensures window state is restored exactly when the compositor is ready, eliminating race conditions and visual glitches. - Implemented strict cleanup for actor signals to prevent memory leaks, ensuring listeners are disconnected immediately after firing (one-shot) or when the window is destroyed.
Try-catch wrappers and `=== 'function'` checks can be avoided by (line 155, 165 `extension.js`). ```js window?.disconnect(id); ``` and ```js actor?.disconnect(id); ``` Is there any reason you didn't use that? Gives you error?
Hi, and thanks for the review! Regarding the try-catch blocks (lines 155, 165): While I agree that ?. is cleaner for standard null/undefined checks, the try-catch wrappers are necessary here due to the specific behavior of GJS/GObject wrappers. In GJS, a wrapper object (like window or actor) can remain defined (non-null) in JavaScript even after the underlying C GObject has been finalized/destroyed. In this "zombie" state, window?.disconnect(id) would pass the null-check but then throw a critical error (e.g., "Object is not valid") when invoking the method. The try-catch blocks are strictly there to suppress these specific invalidation errors during cleanup/shutdown sequences and prevent spamming the system logs. However, I can certainly simplify the typeof actor.disconnect === 'function' check to use optional chaining inside the block if you prefer, but I believe the error suppression is safer to keep. Thanks again!
1. `window?.disconnect()` shouldn't throw an error. If removing the wrapper causes a fatal error, you should look for any bad cleanup before that call. 2. To have a much easier job for cleaning up, use `.connectObject()` and `.disconnectObject()`. That way, you are just disconnecting signals from `this` object instead of signal id. If you have any issues implementing it please join us on GNOME Extensions Matrix channel: - [GNOME Extensions Matrix Channel](https://matrix.to/#/#extensions:gnome.org) - IRC Bridge: irc://irc.gimpnet.org/shell-extensions
Hi, Thank you for the feedback and the suggestion regarding connectObject. I wasn't aware that connectObject was the preferred pattern here, but looking at it, I agree it significantly simplifies the signal lifecycle management and cleanup code, removing the need for manual ID tracking (and the related try-catch defensive logic). I will refactor the code to use .connectObject() and .disconnectObject() as suggested and submit a new version. Thanks for pointing me in the right direction!
Deja Window