Add a little more text and context to your user experience. Creates a top bar “context” button with the focused window’s icon and title, or an app grid icon if no window is focused. Optionally shows a more customizable clock, the user/host name on the system menu button, and a message on the lock screen. The context button can function both as a toggle from desktop to apps, windows, and back to desktop when clicked, and as an app menu when activated using the secondary mouse button, long-press, or a keyboard shortcut.
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 50.6 (11) | Active |
| 50.5 (10) | Active |
| 50.4.3 (9) | Active |
| 50.4.2 (8) | Active |
| 50.4.1 (7) | Rejected |
| 50.4 (6) | Rejected |
| 50.3 (5) | Rejected |
| 50.2 (4) | Rejected |
| 50.1 (3) | Rejected |
| 50.1 (2) | Rejected |
| 50.0 (1) | Rejected |
What's the reason for the function check (line 159 `widgets/contextButton.js`)? Isn't that suppose to always exists?
It's supposed to always exist, but in case that (or something else that the patch depends on) changes in future GNOME versions, I want the patch to be canceled gracefully instead of proceed and break, until the code has been updated.
Approved but those checks are unnecessary. If it doesn't exist in later GNOME it should break. That way, you know what needs to be fixed. If it is cancelled, it means you won't be able to know where the issue needs to be fixed.
Thanks! The reason is that those use a _ prefix, so in general I treat them as internals that may change. If no _ then I wouldn't check and the code should break instead, as those are more public interface and part of the "contract". I think features that depend on internals should be enabled if possible, otherwise not, while basic functionality always keeps working. Or that's the idea.
Context + Window Title