Shows a button on the edge of the screen for each minimized window. Click to maximize again. Includes a settings page that lets you customize it: - Position: top, bottom, left and right - Show in Overview (or not) - Per Workspace Buttons (or always show all buttons) - Cover behaviour: front, leave space, autohide, autohide always. - Margins Touch support is considered experimental at this point. Scroll and autohide not working properly on touch input.
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 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.