Shows a button on the edge of the screen for each minimized window. Click to maximize again. Includes settings that let you customize it: - Position: top, bottom, left and right - Cover behaviour: front, leave space, autohide and autohide always - Button Style - Margins - Show in Overview (or not) - Per Workspace Buttons (or always show all buttons) - Drag-and-Drop behaviour Touch support: With the right settings, the extension is actually becoming quite usable on touch-only devices: - enable drag scroll hack(Settings/Misc.): use button drag movement to control container scroll, since touch scroll is not working on the button-container. - autohide global event hook(Settings/Misc.): for autohide on touch devices. its insanity, but works fine. But only use it for touch AND autohide. - Autohide: set detect container size (Settings/Cover Options). Size 1 works for nicely calibrated touch display, especially with a pen. Adjust size if that is not working for you. - enable snapback (Settings/Misc.): snap back button if dropped outside the buttoncontainer. lets not have windows open on lazy swiping.
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 11 | Active |
| 10 | Active |
| 9 | Active |
| 8 | Active |
| 7 | Rejected |
| 6 | Rejected |
| 5 | Active |
| 4 | Rejected |
| 3 | Active |
| 2 | Active |
| 1 | Rejected |
1. Please don't make the default class you are exporting in `extension.js` that large. It makes the review process super hard. You can make it as small as possible (maybe max 30 lines) and move the logic to another class. 2. There are some properties you didn't destroy or null out on disable. For example, line 852 `extension.js`. Didn't review the `extension.js` for that fully since that should be reviewed again after the default class change for the next one.
1. Ok, refactoring was on my radar, was planning on doing that on a future update, but you are right, extension.js is too large already now. Need to readjust my radar... So with 30 lines, there will only be a enable() and disable(), and those will only initiate and close the new logic classes. I guess, its not the idea to have a new single super long class outside extension.js. But instead have several smaller classes that separate things in a well readable way. It will be a challenge to separate things in a useful way, because things are strongly interconnected. Challenge accepted. 2. Ok, got to figure out that one on line 852. (settings) Am I ok, do just destroy() the buttons without disconnecting their click-handler? (that was in every version until now) Of course, the handlers on things that i do not destroy on disable(), they have all to be properly disconnected. those in "HOOKS THAT DONT DEPENT ON CHROME" have their value saved and are disconnected.
1. I'm not against long classes but not for the entry point since the property check for cleanup will be super hard. Maybe the entry point of my extension can give you an idea: [Just Perfection Extension](https://gitlab.gnome.org/jrahmatzadeh/just-perfection/-/blob/main/src/extension.js) The idea is to make everything easily traceable and readable. For example, each file one class is a good idea if you've decided to go to the multi modules route. 2. If the button is destroyed on disable, no need to remove the signals of that button. Just destroying that would be enough. For the settings instance, it is always a good idea if you disconnect before nulling out but it can pass just by nulling out since that's not a GNOME Shell settings.
I see, you are clearly not an enemy of long classes. I will still try to separate things if it makes sense. But its good to know, that if a lot of things belong together, the class is allowed to be big. Just not the entry point. thanks for the review.
Minimized Windows Buttons