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.

Sign up for GitHub

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

Jump to bottom

TSE: Replace TSM.Profile with a ProfileViewModel #8552

Merged
merged 2 commits into from
Dec 11, 2020
Merged

TSE: Replace TSM.Profile with a ProfileViewModel #8552

merged 2 commits into from
Dec 11, 2020

Commits on Dec 11, 2020

  1. TSE: Replace TSM.Profile with a ProfileViewModel 

    It's generally accepted that in a graphical application you'll follow a
design pattern. The one this moves us towards is "MVVM" -- Model, View,
View Model.

In an ideal world, _all of our display smarts_ would be in the
ViewModel and the View would literally just be XAML. This moves us
closer to that reality.

The only thing the Profile page ViewModel does right now is proxy
requests through to the Profile behind it while adding some basic
invalidation logic and detection of a setting being set to its current
value.

We have to do this because (1) MVVM is better and (2) separation of
concerns dictates that TSM::Profile should **not** have a
Windows.UI.Xaml dependency (in IPropertyChangedNotifier). It therefore
**cannot** conform to Xaml's notion of what a ViewModel should be.

I've done this by introducing a heap of code-generating macros and a
template that work together to make the process of adding more settings
easier (if not "easy").

We are eventually going to need to do this for all of the existing TSM
model objects. In an ideal world, even our navigation would be driven
through a viewmodel that supports a notion of an "active page".

All I've done so far is break ProfilesPage's dependency on Profile entirely.
Weird how that works.

Fixes "browse buttons do not actually update the profile"
Fixes "we need to have convoluted local overrides that update the
  visiblity of things like AcrylicOpacity"
Fixes "we'll eventually need a way to update a preview TermControl"
Fixes "we have no idea how we're going to update the Discard/Apply
  buttons or the unsaved changes label"

Having a PVM that notifies on icon/name change will also make it easier
for the MainPage to update its NavViewItems.
    @DHowett
    DHowett committed Dec 11, 2020
    Configuration menu
    Copy the full SHA
    df1d9e9 View commit details
    Browse the repository at this point in the history

  2. This is a header file so it follows clang rules even though it's for idl

    @DHowett
    DHowett committed Dec 11, 2020
    Configuration menu
    Copy the full SHA
    35fdece View commit details
    Browse the repository at this point in the history