Classic App Switcher is a 🖱️ Mouse friendly application switcher for GNOME inspired by the classic Mac OS. The minimal design blends discreetly into the GNOME UI, providing a familiar workflow for users transitioning from macOS while respecting GNOME's design principles. **Key Features:** - Panel button shows the currently focused application and opens a menu with window management functions - Lists running applications on the current workspace - Easily hide an app and retrieve all of its open windows - Hide all other apps/windows allowing you to focus on the active window - Window count showing visible and hidden (or minimized) windows and apps - Workspace-isolated behaviour for fluid multi-workspace workflows - New in v2.0: Panel Button Scroll - Scroll DOWN to toggle between focused application and most recent below. Scroll UP to cycle through open application stack in reverse order (back-to-front - requires at least 3x open apps!) - New in v2.0: Optional Mac Style keyboard shortcut support! - Complements native GNOME features (Activities, Dash, Dynamic Workspaces)
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 2.1 (10) | Active |
| 2.1 (9) | Active |
| 2.0 (8) | Active |
| 2.0 (7) | Rejected |
| 2.0 (6) | Rejected |
| 1.0 (5) | Active |
| 1.0 (4) | Rejected |
| 1.0 (3) | Rejected |
| 1.0 (2) | Rejected |
| 1.0 (1) | Rejected |
1. Unnecessary try-catch wrapper (line 83, 1013, 1031, 1082, 1126, 1136, 1254, 1267 `extension.js`). For something like 1083 `extension.js` simply return if the window isn't there anymore. ```js if (!win) { return; } ``` or: ```js return win?.minimized && win?.get_workspace() === workspace; ``` 2. Not a good idea to change the GNOME Shell keyboard shortcuts through extensions. They may not revert as user expected. The better idea is to pick a different shortcut than default.
Thanks for the rapid review, did not expect this to be looked at on a Sunday! Ok, I appreciate point 1 and will address but could you please clarify point 2. - This feature is opt-in and we fully clean-up on enable-toggle and extension disable. It took a lot of work to determine optimal shortcuts and research existing usage so would prefer to stick with this pattern if possible. I did not think this would be an issue as other extensions remap Super which is a core part of the GNOME UX - Do you mean repurposing is never allowed, or just that I need stronger reversion guarantees/user warnings? If the latter, I'd appreciate guidance on what would make it approvable (e.g., schema reset or fallback bindings). as I thought I had covered this and testing does show we are reverting to defaults...?! Regards
For keybinding, this is the faulty revert behavior: - User enables the extension. - Key is changed to `[]`. Original is stored (`Super+H`). - Restart. - Enable extension on login. - Store the original value which is now `[]`. - User disables the extension. - Key restored to `[]`. IMO, it's not a good idea to change anything from GNOME Shell settings since users won't expect the extensions changing something from GNOME Settings.
Ahhh! I see... right, like I said this was thoroughly tested but obviously I missed this angle! - So tell me, if I resolve this issue is this still a no go? My thinking here is that while I have 'borrowed' this the repurposing does not really change visible behaviour for most users who simply consider this as 'hide' given they are generally using this with a single-window app so most would never even notice the difference - given it IS opt-in and we clearly state the behaviour change and even provide an alternative method with undo via Super+M/Alt+Super+M I felt this was a pretty safe modification considering! I note you have not mentioned Super+M here and have focused on Super+H This is one of 8x shortcuts provided by this extension (purely as an 'accessible' feature) but the pattern flows from this... H for 'Hide' M for 'Minimise and U for 'Unhide' - It would really change the flow here if I have to ditch this and to be honest would rather drop this enhancement altogether if this is the case. I appreciate this history around this subject and am not claiming to know better here, it was just a personal choice having been Mac based forever and having the combo-keys hard-wired in my fingers and brain! :0) - I am also paying homage to the classic mac os here and while this is supposed to be a re-imagination for GNOME the retro vibe has really changed my flow having been using this daily myself and indeed developing it while it was enabled on my local system - loosing this would really impact the whole purpose, I hope we can find a compromise here... :0(
`Super+H` was just an example to show you how the faulty revert can happen. It can happen to any keys that you do the same. #2 wasn't the reason for reject. Just a reminder that changing the GNOME gsettings value can cause some unwanted revert results. You definitely don't want users getting angry at you after uninstalling or disabling your extension. The change that cannot even be reverted after remove and restart.
Understood, I will address all of this and ensure it is thoroughly tested - to be fair this was an 'edge case' scenario and while not ideal is not quite as destructive as it sounds given there is a big red 'Reset All' button in Settings but you are right, most users will likely miss this and throw a hissy fit so I will be sure to avoid! Many thanks for your time and I appreciate the nudge, have a nice evening 😜