Disable features that conflict with Dash to Panel #420
Conversation
This allows us to detect whether Dash to Panel is enabled in the user's session, and perform the following changes: - Disable panel opacity control, Dash to Panel has its own - Disable the custom workspace button and leave Activities in place - Disable handler for "panel follows monitor focus" - Grey out "panel follows monitor focus" and add explanation tooltip
| if (this._settings.get_boolean('found-dash-to-panel')) { | ||
| topbarFollowFocus.set_sensitive(false); | ||
| topbarFollowFocus.get_parent().set_tooltip_text("Incompatible with Dash to Panel."); | ||
| } |
There was a problem hiding this comment.
Ideally I'd like to follow HIG and add an icon next to the toggle to signify that something is up
| @@ -2270,7 +2275,7 @@ function registerWindow(metaWindow) { | |||
| if (metaWindow.clone) { | |||
| // Should no longer be possible, but leave a trace just to be sure | |||
| utils.warn("window already registered", metaWindow.title); | |||
| utils.print_stacktrace(); | |||
| //utils.print_stacktrace(); | |||
There was a problem hiding this comment.
This change speeds up unlocking session drastically.
| <key type="b" name="found-dash-to-panel"> | ||
| <default>false</default> | ||
| <summary>Automatically set on startup when Dash to Panel is enabled. Any changes to this setting will be reset.</summary> | ||
| </key> | ||
|
|
There was a problem hiding this comment.
Apparently prefs.js can't access extension constants -- it exists outside of the extension manager, so I had the extension leave a message for the prefs view to find afterwards.
|
@smichel17 review please? It's been a while and these patches are still relevant |
|
Overall: I think it seems reasonable, but I am concerned with maintainability. How much compatibility code are we willing to take on (e.g. for other extensions), and what level of support do we want to maintain for it (e.g. if we want to add a new feature to PaperWM, is it okay to break extension compat or do we want to test all that first)? Those questions make me want to look over this code and think about the architecture more closely than the skim I did a few months ago and yesterday, but I'm not sure when I'll get around to that. Maybe a compromise in the meantime: would you be up to commit to maintaining it? |
|
I'd say compatibility is only really a concern for extensions that conflict with PaperWM and are susceptible to be installed alongside it. But yeah, the compat patch is relatively simple, I think I'll be able to maintain it. by the way, have you had a look at #421 yet? It's mostly unrelated but a nice touch for convertible and tablet users. |
|
Life and work are a bit complicated right now, not much bandwidth. #421 is a draft so I didn't look at it. |
|
A few things here - looks like you're wanting to merge into I understand the intent here but I don't think we should be doing things specifically for any specific extension (even if it's a very cool one with dash-to-panel) - for some of the reasons @smichel17 mentioned. Instead, we should simply make each of these options (and others) settable via dconf - and well documented. For example, we've recently released #476 - which you can disable it entirely via dconf with a: which you'd probably want to do if using We could actually add similar dconf options for opacity, showing/hide workspace or activities button etc. This makes it much more configurable rather than having external extension specific code (e.g. what if I want to use |
|
@jtaala yeah, that makes a lot more sense |
This allows us to detect whether Dash to Panel is enabled in the user's session, and perform the following changes:
Also added wallpaper refresh on unlock (Night Theme Switcher) and a couple fixes when locking session