Closed worldofpeace closed 4 years ago
This also makes me think: we should probably have a comment with why on all overrides. There are reasons behind each but sometimes it's hard to remember.
auto-maximize
is intentionally false. The others are open to discussion.
Thanks, though how have you closed the discussion on auto-maximize
? Is there some precedent in your tracker that I'm not aware off? I'd be more open to dropping this change if it didn't appear you decided this for me.
This also makes me think: we should probably have a comment with why on all overrides. There are reasons behind each but sometimes it's hard to remember.
Very much so, git-blame here wasn't helpful for these types of things.
@worldofpeace
I'd be more open to dropping this change if it didn't appear you decided this for me.
Well, you can do whatever you want downstream but we've decided this a long time ago for elementary OS. I've expanded on my code comment above, as well. I'm not sure where the original discussion took place (probably on IRC back when we used Launchpad, honestly), but this is still very intentionally the design of how Pantheon works.
@worldofpeace
I'd be more open to dropping this change if it didn't appear you decided this for me.
Well, you can do whatever you want downstream but we've decided this a long time ago for elementary OS. I've expanded on my code comment above, as well. I'm not sure where the original discussion took place (probably on IRC back when we used Launchpad, honestly), but this is still very intentionally the design of how Pantheon works.
Thanks, I think this feeds into the point that default settings in elementary OS lack documentation. And I prefer not to change defaults like this downstream if possible, especially when it it's a design decision you've made for the DE. It could reflect poorly on Pantheon and give confusion as to why there's differing behaviors. Usually only needed when there's a consistent user feedback something is degrading user experience for us specifically. And even then trying to avoid fragmentation.
@worldofpeace as annoying as it might be… could you propose each of these as a PR? That way each can be discussed/tested/merged on their own without holding the others up.
@worldofpeace as annoying as it might be… could you propose each of these as a PR? That way each can be discussed/tested/merged on their own without holding the others up.
Possibly. Would multiple commits be acceptable? I don't think much of the changes here are controversial, so testing a PR commit by commit could be similar.
Eh, multiple PRs fits in with the GitHub and elementary workflow better and makes it more likely at least some of these changes will be accepted more quickly.
Eh, multiple PRs fits in with the GitHub and elementary workflow better and makes it more likely at least some of these changes will be accepted more quickly.
Will do, there's an "elementary" workflow? (semantically I'm expecting it to value simplicity :smile: )
Yes, one change per PR for ease of testing and merging on its own merits. ;)
Superseded by https://github.com/elementary/default-settings/pull/139 https://github.com/elementary/default-settings/pull/140 https://github.com/elementary/default-settings/pull/141
I rescinded the auto-maximize change.
Breakdown of dropped settings:
Introduced in de894b7f76fdb0b06523ab8b73a694447036fe72.
org.gnome-settings-daemon.plugins.cursor This was introduced to workaround a bug where cursors would be invisible with g-s-d. The report 0 was never actually closed, and I haven't noticed any one's recently. I believe the issue is now gone in recent versions. ( reports mentioned gtk 3.10)
org.gnome.settings-daemon.plugins.power
ambient-enabled=false
idle-dim=false
These are just powersettings that are defaults in g-s-d that appear to be completely sane.
I've been using this in NixOS and Soon™ a downstream patch like the rest of the PRs in this repo...