mitchcapper
commented
1 year ago So "Change Cell Orientation in code to better match the logical expectations" commit doesn't work properly. Everything seems to be fine except for the drag over. When you drag over the drop regions are opposite orientation (so if you have a vertical split with 2 tall cells when you drag over it had the entire bottom half of the window drop for the right cell and the entire top half for the left).
I looked over what I could find in UE CellVisualizer and Cell API calls and all the orientation terms seem to be correct to me. That would lead me to think it may be something in EasyXAMLTools doing this. I looked again at reverting this but the terms in my mind seem to make sense with this change.
A vertical split has a vertical orientation for a cell, it results in a horizontal stack panel (aka cells stacked left to right) and a vertical panel resizer between cells.
GetGet99
There are some commits in this PR not directly related to the PR itself. I also did not squish the PR for this reason. They can be put in as separate PR but to make merging a bit easier did it as one PR with multiple commits (these are all the initial commits and are commented to their purpose).
Even though this PR is large I wouldn't make a release including it yet. It probably deserves some internal testing first and like a few more changes to make it a bit more user friendly. Still didn't want it to grow further in complexity for the initial review.
There is code commented out in a few select spots where I would have liked to do X but couldn't, normally not a big fan of leaving code that isn't used in but might prevent someone wasting time trying the same without knowing why it won't work, and if the WinUI limitations are fixed can be used at that point. Could also be hidden behind feature flags.
The main idea of profiles is to allow layered / stacked settings to exist. Rather than just one config used for all the settings (even if you let the user choose which config) this designs is so a config can contain only partial settings that get put on top of the current instance. The app starts with an internal "default config" if a default config exists that is loaded at startup and any entires in there override the internal defaults.
Further in the user requests an addition config be loaded (--profile cli) or from the settings menu this gets applied on top. Configs can store certain settings or can store tabs/cells to restore.
Right now when exporting the config it only exports everything, but you can manually remove things from the json to do partial profile loads. There is only one setting right now at export "All or just things different from defaults" but because of that I don't automatically close the window when you pick the filename in the browse dialog to save to (you have to actually hit save). In time I think this should grow to a tree dialog showing you all the settings it will export with checkboxes next to them to disable them.
The load dialog also doesn't automatically activate until you hit load, but here it may make sense to automatically close it and load when you select a profile (as no other settings). This could be easily done (as the code is already commented out) in EpxortImportInputViewModel around line #69 (with a check to make sure on Save NotLoad.
Almost all config file settings are nullable specifically to allow empty /false to be determined separately from null. A settings file with the titlebar override set to empty string "" is very different from one that does not set it at all. If it is set but empty that means the existing titlebar will be set to empty (if not already) if in the loading profile it is missing/null however then nothing happens.
Certain refactoring was done to allow for external cell/window creation.
This adds the import/export buttons to the settings menu Adds new UI for ExportImportVM that prompts user for basic settings and the profile to use.
Removes FauxSettings and FeatureFlags and merged the remaining required items into the USConfig class.
Some of the new settings were added to the settings page, most are json config only.
When exporting you can select to export all settings rather than just those that differ from the defaults to see what others are the re.
Removed the setter background thread for Settings window we now properly dispatch where needed on setting changes.
PreservedHelpers.cs - These functions follow the idea of if this property is set in the new profile, override the current property as long as it is valid, otherwise throw an exception. Sadly all functions here are duplicated to support full value type/struct args. I couldn't figure out how to properly cast a struct arg call to call the class version, mostly because behind the scenes a Nullable value type is quite different from a Nullable reference type. A hope would have been something like: public static SRC_TYPE DoOrThrow(SRC_TYPE? data, Action OnSuccess, Func<SRC_TYPE, bool> MustBeTrue, Func? OnFail = null) where SRC_TYPE : struct => DoOrThrow(data,OnSuccess,MustBeTrue,OnFail); This would not work for all situations though. This class also contains some color converter helpers as WinUI color class is quite lacking.
PropHelper.cs - Allows copying properties from one instance of a class to another, optionally recursively. The recursive flag is quite 'dangerous' as it tries to recurse into sub value/reference types and work on each property individually. This was needed to avoid a lot of boilerplate code for Clone() and dealing with config classes with sub classes etc. To try and prevent accidental failure it is scoped to only work on our specific classes, not on arrays, and not on primitives/enums. Was lazy here and didn't want to go through and fix all the nullable options so just disabled all warnings.
WinUI manual theme setting is basically broken, so stopped users from being able to pick a theme (Sad as live theme changes would be nice and easy to implement).
There is a USConfig class, this is very close to just being an alias for SavedInstanceData (the root class for saved profiles) but is an easier name to read while keeping SavedInstanceData in line with all the other profile data classes.
To keep some classes/code as close to existing as possible there are some oddities where properties are forwarded to another class. These could be changed.
Automatically close our settings pane when it is likely the user would not pick another action from it (more true flyout style).
Settings are only for the running instance unless the user selects SaveAsDefault which makes them the defaults.
I have one additional set of test cases for CellCreation I will put in a separate PR after this. They should not be merged into master but we should look to see if they warrant us making any changes to fix some of them.