Cleanup settings in override

worldofpeace commented 4 years ago

Breakdown of dropped settings:

auto-maximize=false I believe its been discussed in the gala issue tracker that it's desired for almost fullscreen windows to be auto maximized. And notoriously I've noticed this with applications like epiphany, where it's allmost fullscreen, and it makes the panel look very strange not being completely opaque and having a gap. I haven't noticed issues with it being set.

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...

cassidyjames commented 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.

worldofpeace commented 4 years ago

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.

worldofpeace commented 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.

Very much so, git-blame here wasn't helpful for these types of things.

cassidyjames commented 4 years ago

@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 commented 4 years ago

@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.

cassidyjames commented 4 years ago

@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 commented 4 years ago

@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.

cassidyjames commented 4 years ago

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.

worldofpeace commented 4 years ago

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: )

cassidyjames commented 4 years ago

Yes, one change per PR for ease of testing and merging on its own merits. ;)

worldofpeace commented 4 years ago

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.

elementary / default-settings

Cleanup settings in override #138