[GUI] Add Preference Pack support #4787
Conversation
| <FCBool Name="Std_SelectionView" Value="0"/> | ||
| <FCBool Name="Std_ComboView" Value="1"/> | ||
| <FCBool Name="Std_ReportView" Value="0"/> | ||
| <FCBool Name="Std_PythonView" Value="0"/> |
There was a problem hiding this comment.
Worth listing 'Tree View', 'Property View' and 'DAG View' ?
There was a problem hiding this comment.
Yeah, probably. Right now that file is purely a skeleton for testing, I'd love some help fleshing it it, and creating other Behavior templates.
There was a problem hiding this comment.
I have added those three, but will leave this conversation open in case other additions come up.
There was a problem hiding this comment.
At the suggestion of Forum member jnxd I have added Editor font information into a template file.
Preference Packs are collections of preferences that can be applied en mass to the user's current setup. Any preference that can be stored in user.cfg can be stored in a preference pack, and they are designed to be easy to distribute. Support is also added for saving a subset of current preferences into a new preference pack in order to facilitate easy creation of new "themes", etc.
berndhahnebach
added
the
Core
|
@chennes would mpetrikas's VerticalUI be a good usecase for this ? |
Fo some of mpetrika's suggestions, yes: the ones that are just preference-driven, or are part of the Qt Theme system. But other suggestions in that post are not things that are (currently) stored as user preferences, and do require code modifications. |
|
@chennes here is my test report: |
|
This looks like a mastery addition... Will test too ASAP! |
Just changing the preference for hiding or showing a dock window does not actually trigger a state change. To enable that, the preferences pack manager must manually instruct the DockWindowManager to save its state into the preferences before storing a preference pack, and must instruct the DockWindowManager to load its new state from the preferences after loading a pack.
Thanks again for testing: I've pushed a fix to the bug you discovered. |
|
Thank you for the fix. Now everything is fine ... only one minor issue remaining? See https://forum.freecadweb.org/viewtopic.php?f=8&t=58210&start=40#p526935 |
Why not just use "Preferences Preset" and store in |
No particular reason for "Preference Pack" - we discussed it in the forum and that was the consensus. Basically the same for the xml file, though also note that that file is not specific to Preference Packs, the intention is that in the long term all mods are distributed with that file, so we stuck with the "standard" filename as used in that ROS specification. |
|
Following a link to the branch on the CI-repository: https://gitlab.com/berndhahnebach/FreeCAD/-/commits/PR_5060 The CI-status is available on the latest commit of the branch. https://gitlab.com/berndhahnebach/FreeCAD/-/pipelines?scope=branches |
|
FreeCAD CI-repository: pipeline: status: all pipelines for each branch: |
There was a problem hiding this comment.
This is pretty cool! I tested on Debian testing and everything seems to work as expected, no regression or bug noted.
Observations (generic suggestions, don't consider these as needed for this PR, I let you choose if you consider this PR ready or not):
- The "preferences pack" section uses quite a lot of the "General" preferences page. I wonder if it wouldn't be better in its own tab
- It is unclear what the "Manage" button is for. It opens a file selection dialog without explanation
- The template type in the available pref packs seems to me rather unuseful info.... I'd rather see maybe a description text, ie what will happen if I press "apply"
|
Thanks, @yorikvanhavre .
|
|
ok! the description could be in a tooltip maybe.. |
In display, show the "tags" instead.
|
OK, I've addressed your comments above: I removed the "type" thing and replaced it with a display of the tags assigned to the pack (those are set in the metadata file). Eventually it would be good for a user to be able to edit those from the GUI, but that can be later work I think. From my perspective then this is ready for merge. |
|
|
|
Ok let's do it then! Thanks for the very clean coding BTW, even I can find myself in it ;) |
|
Thanks, I was too much a coward to press the button myself 😄 |
|
So far so good 😅 |
Summary
This PR adds a system for storing and applying sets of user preferences called "Preference Packs". These are intended to give users the ability to make bulk modifications to their FreeCAD setup by applying one or more of these packs. The packs are designed to be distributable, and to that end this PR introduces a new type of metadata file, "package.xml". Anything that can be stored in the user.cfg file can be stored in a Preference Pack. More details can be found in the "Details" section below.
Testing
The main questions to be addressed in testing are:
Before testing, please back up your user.cfg file. If the tests fail it is likely that your preferences will be corrupted. Although the system makes backups, if there is a problem with that code, you may lose your settings!
Suggested Test A - Stylesheet change
Expected results: the stylesheet is reverted to "None".
Suggested Test B - Color change
Expected results: the color change is reverted to the original default.
Suggested Test C - Un-reverted change
Expected results: your change is not affected by the pack.
Suggested Test D - New appearance preference pack
Expected result: the change you just made is reverted to the color you stored in the preference pack. Your preference pack is listed as an "appearance" pack in the GUI.
Suggested Test E - New behavior preference pack
(Only a few behaviors are encoded into the preference pack template files in this PR: it is expected that more will be added in later PRs in consultation with testers and users)
Expected result: the shown/hidden state of the Dock windows is restored to that which was stored in the preference pack.
Details
This PR comprises three main additions to FreeCAD:
App::Metadata
C++ and Python support for reading and writing the new metadata format. That format is based on REP 149, with minor modifications to accommodate use within FreeCAD. The format is documented at https://wiki.freecadweb.org/Package_Metadata.
Preference Packs require this file to be present and to describe the pack, and the long-term goal is that this metadata file can be added to other types of Add-Ons, facilitating a more powerful add-on manager, and eliminating the need to compile in external workbench icons, etc.
Gui::PreferencePack
This class manages a single preference pack, which itself is made of a number of separate files, grouped together into a folder with the same name as the preference pack (as described by its package.xml metadata file).
A preference pack consists of the following files (all technically optional):
Preference Packs provide an additional piece of guidance to end users, describing whether the pack is intended to change FreeCAD's appearance, behavior, or both. This is purely GUI guidance, and is not enforced by the code in any way. It is set via the "type" element in the package.xml metadata file.
Because of the sensitivity of user preferences, and the possibility that a pack will make a change the user does not like that is not discovered immediately, when applying a pack two separate backups are taken. One is used to roll back the most recent change in the event that post.FCMacro raises an exception, and the other is a set of backups managed by the PreferencePackManager (described next) and retained for one week. There is currently no user interface for rolling those back, they must be manually copied by the user.
Gui::PreferencePackManager
This class manages a list of all available preference packs, and also provides the ability to save the user's current settings as a new pack.
Preference Packs are searched for in three locations:
To locate the packs, files named "package.xml" are searched for in the above locations. If found, that metadata is read in and examined for "preferencepack" content items. These items must all have unique names (as specified by the metadata), and their files must be located in a subdirectory of the same name as the preference pack.
Saving preference packs
To ease the development of distributable preference packs, the ability to save a subset of the user's current preferences into a preference pack is also provided. However, this facility requires some additional complication due to the way FreeCAD handles default preferences.
The ability to save to a preference pack is provided by including a set of "Preference Pack Template" files. These are needed to support saving of preferences that the user has not explicitly set, and are using their hardcoded default values -- in that case, the user.cfg file does not have any information about the current setting, which is only currently available in the code that accesses that setting.
To overcome this obstacle, Preference Pack Templates are intended to provide a complete "user.cfg"-formatted set of preferences set to their default values. When a user selects "Save as new" in the GUI, several locations are scanned for these template files:
(the alternate directory name "preference_pack_templates" is also supported, for those mod authors who prefer to use snake case). Within these directories, two subdirectories are searched, "Appearance" and "Behavior". Template files should be grouped into preferences that affect only the appearance of FreeCAD, and those that change its behavior.
The user is presented with a set of checkboxes to select which of these templates they would like used to determine which preferences are stored. This feature is mainly intended to provide "Theme" authors with an easy way of creating new preference packs with UI color information in them. To that end, a relatively complete set of templates is provided for UI color information, and only a single "demonstration" template is included in this PR with other preference information in it. In the long term it is expected that a robust set of templates will be developed and included with FreeCAD covering the most-requested Preference Pack settings.
Future Work
A separate PR will provide an extension to the Add-on Manager to support the new package.xml data, and to add "Preference Pack" as a new type of add-on. For now, packs can be managed as a standard add-on, as long as they provide a package.xml file and follow the appropriate folder structure and naming convention. This includes manual installation into the Mod directory.
Forums discussions