-
-
Notifications
You must be signed in to change notification settings - Fork 377
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
PICARD-9: Add support for user profiles #1851
Conversation
I added a working version of the profile editor dialog, which I've been using for local testing. Once we firm up structures and such, I'll see about adding some tests as well. EDIT: I suppose the dialog should have been in a separate PR, but I thought it might prove useful for any testing that you might want to do. EDIT 2: I think the system now works as described by @zas in https://tickets.metabrainz.org/browse/PICARD-9 |
c2e5a8d
to
2b0f0f1
Compare
2b0f0f1
to
20ca5ec
Compare
I did a quick test, it works well. That's a good improvement already. Good job! |
It should be fairly easy to store the profile settings dictionaries by profile id under a new |
00f1cc2
to
6ea6136
Compare
After moving the profile settings to a new |
6ea6136
to
2ea04a4
Compare
I think that's due to the use of global Line 142 in 2ea04a4
Use Line 150 in 2ea04a4
Line 162 in 2ea04a4
Line 185 in 2ea04a4
Line 187 in 2ea04a4
|
That was exactly the problem. THANK-YOU! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just (few more) stylistic remarks, but the patch is very good ;)
Named tuple profile settings
In `picard/ui/profileeditor.py`: - Remove unnecessary `deepcopy()`. - Use `set.difference()` for comparing key sets. - Add explanation for creating missing key in `get_settings_for_profile()` method. - Move `settings` declaration into `if` section where it is used. - Remove unnecessary `.keys()` call when creating set of profile IDs. - Use `set.difference()` for comparing setting sets. - Remove unnecessary `self.loading` check. - Add class constant for which QTreeWidgetItem column to use. In test/test_profiles.py: - Use keys defined in `SettingConfigSection` class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work. This works really well, and I am especially glad that this was possible with rather small and clean changes to the config module itself.
From a user perspective I find the settings concept rather difficult to grasp, but it is very flexible. Before deep diving into the code itself I tried this functionality from a user's perspective. But I definitely had to read the documentation to fully understand it (even though I had kind of suspected how this works based on our previous discussions).
I have a few notes about the profile editor dialog itself:
- The buttons should be placed in
QDialogButtonBox
and should be added with appropriate roles. This ensures the buttons render consistent with other dialogs and platform dependent. - I find the separate "Save" and "Make it so!" buttons really confusing and not easy to use. I'd favor having this behave like options themselves: Have a "Cancel" button and a single "Make it so!" button to save and close
- I would consider moving the "New", "Copy" and "Delete" buttons below the widget, next to the ordering buttons. That would make it consistent with other widgets we use in options where the buttons to control a list of things (e.g. scripts) are next to the widget presenting this list. It would also make the main dialog buttons look less cluttered
I would also add a keyboard shortcut to open the profile editor. Ctrl+Shift+P
maybe? That would allow the user to quickly change profiles without the menu.
For a future refinement to make the behavior of profiles more clear I think it would be beneficial to indicate in the profile editor which settings actually have distinct values. Maybe even show the value itself (which would probably require that we have a useful rendering depending on the option type, e.g. show BoolOption as "Yes" / "No" or something.
But we can do this in a follow up PR.
Most were in the buttonbox, except "Make It So!". Now are all in buttonboxes with the appropriate roles assigned.
I actually simplified it by removing the "Save" button and auto-save the changes locally (within the dialog) as they are made. Do we still need a "Reset" button?
Done. I agree that they look better there.
Done. At the same time I also added one for the file naming script editor to be consistent. I hope that's okay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The dialog now looks much clearer with re-arranged buttons.
LGTM
Summary
Problem
There has been a long-standing request to allow for different user settings profiles, with a quick and easy method for switching between profiles. The plan for implementing user profiles involves maintaining a stack of profiles that would be applied sequentially (for active profiles in the stack). See the discussion on the JIRA ticket.
Solution
Implement a new subclass of
ConfigSection
to use for user settings that applies the user profile stack automatically to allconfig.setting
assignments and retrievals. Add new keys to store the user profiles list and settings (overrides) for each profile in a newconfig.profiles
section. Add a new dialog accessed from the main screen menu to manage the user profiles and settings.Action
Additional work to be completed when this is finalized: