Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save and restore last-opened plug #132

Closed
wants to merge 10 commits into from
Closed

Save and restore last-opened plug #132

wants to merge 10 commits into from

Conversation

cassidyjames
Copy link
Contributor

@cassidyjames cassidyjames commented Dec 6, 2019

Fixes #101

  • Add GSetting
  • Save state
  • Restore state

I'm not 100% this is the right way to do it, but it seems to work correctly. Opening from a settings:// link (i.e. Network settings from the indicator) correctly overrides and rewrites the state.

Notes:

  • Bumped AppData release version to a minor release since this is a new feature
  • Fixed indentation in GSchema
  • Renamed settings vars to saved_state and preferences to better distinguish them

@cassidyjames cassidyjames marked this pull request as ready for review December 6, 2019 20:06
@danirabbit
Copy link
Member

I've been testing this and I think I'm firmly 👎 on this.

My major problem with it is that System Settings is nearly always a linear workflow. I open something and then I'm done with it and the next time I open it, I almost certainly want to navigate somewhere completely different.

So what ends up happening is that I spend extra time navigating back home before I get to go to the place I want.

Maybe some kind of middle ground could be a timeout where we restore settings within the last 5 minutes (or something really tight like that) or at most in the same session? This would probably cover the case where you've changed something and then decided to immediately go back and change it again, but would be less likely to interrupt the case where you're navigating to a completely different setting.

I'd be interested in some user research to the contrary, but my inclination is that people don't typically change the same settings multiple times unless it's over a very short period of time or a very long period of time (in which case remembering the last used pane doesn't really help anyways)

@cassidyjames
Copy link
Contributor Author

@danrabbit hm, remembering a timestamp of last-closed and then only restoring if it's been less than an amount of time should be pretty trivial. I can give that a try with a short span of a few minutes.

@cassidyjames
Copy link
Contributor Author

cassidyjames commented Apr 15, 2020

@danrabbit alright, I've revisited this with a short one minute timeout. So if you're poking around at a setting, close Switchboard, and re-open within a minute, you get back to where you were. Otherwise, it retains the same behavior as today.

A minute seems pretty short to me, but it seemed like a sane starting point.

@cassidyjames
Copy link
Contributor Author

Okay, something I noticed while testing: it doesn't remember the sub-section you were on, which is annoying. I wonder if I can do something similar to your search results branch where it restores using the settings URL, though I don't think we have a way to know and save that in every plug… hrm.

@jeremypw
Copy link
Contributor

jeremypw commented Jun 8, 2020

I think having a (arbitrary) timeout introduces an element of unpredictability so I am -1 on that. In general you can keep the Settings window open if you are making a series of changes as they usually are applied straight away (or should be).

@jeremypw
Copy link
Contributor

Doesn't look like this is going anywhere ... 2 👎 so far.

@cassidyjames cassidyjames deleted the save-plug branch December 18, 2020 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Save open plug state
3 participants