-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Persist Runtime TabTitle and Maximize/Focus/Fullscreen states #12073
Persist Runtime TabTitle and Maximize/Focus/Fullscreen states #12073
Conversation
- Runtime tab titles - Focus, Maximized, and Fullscreen modes. Also, - Adds actions for Set{Focus,FullScreen} that take a boolean to work in addition to the current Toggle{Focus, Fullscreen} actions. - Adds SetMaximized that takes a boolean. This adds the capability to maximize (resp restore) a window using standard terminal actions. This also involves hooking up a good amount of state tracking between the terminal page and the window to see when maximize state has changed so that it can be persisted. - These actions are not added to the default settings, but they could be. The intention is that they could assist with automation (and was originally) how I planned on persisting the state instead of augmenting the LaunchMode.
2021-12-30.22-44-51.mp4 |
@check-spelling-bot ReportUnrecognized words, please review:
Previously acknowledged words that are now absentadaa coffgroup coffgrp datetime eae emplate GENPROFILE HHmm Hostx installationpath MMdd pgorepro pgort PGU RelayoutTo accept these unrecognized words as correct (and remove the previously acknowledged and now absent words), run the following commands... in a clone of the git@github.com:Rosefield/terminal.git repository
✏️ Contributor please read thisBy default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.
If the listed items are:
See the 🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉 🗜️ If you see a bunch of garbageIf it relates to a ... well-formed patternSee if there's a pattern that would match it. If not, try writing one and adding it to a Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines. Note that patterns can't match multiline strings. binary-ish stringPlease add a file path to the File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.
|
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.
I'm gonna hold my s/o on the maximizedFocus thing, but otherwise this looks great, thanks!
if (_isInFocusMode) | ||
{ | ||
mode = WI_SetFlag(mode, LaunchMode::FocusMode); | ||
} | ||
if (_isMaximized) | ||
{ | ||
mode = WI_SetFlag(mode, LaunchMode::MaximizedMode); | ||
} |
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.
technically, the terminal could be maximized, in focus mode, (which is different than fullscreen), but this would only save it as maximized
, right?
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.
No, this would save potentially Focus | Maximized | Fullscreen if you have all 3 enabled.
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.
derp, that's what I get for reviewing at 7am. I forgot that mode = WI_SetFlag(mode
would be additive like that. Ignore me :P
@@ -463,6 +463,17 @@ namespace winrt::TerminalApp::implementation | |||
state.args.emplace_back(std::move(setColorAction)); | |||
} | |||
|
|||
if (!_runtimeTabText.empty()) |
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.
typically I'd prefer a separate PR just for the sake of potential easy reverts, but in this case meh it's fine, this is a simple enough change
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.
You're not wrong. I just happened to be looking to fix multiple open issues so the runtime text that took 2 minutes and the window state tracking that took an afternoon ended up in the same PR.
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.
Mainly concerned about the side-effects of the TerminalSettingsSerializationHelpers
change. I'd prefer if we could switch to a JSON_FLAG_MAPPER and update the docs/schema all in one push, but that might break the settings UI too. Ugh. Not worth doing in this PR tbh.
So I guess all I want is:
- confirmation that the global setting works as expected with the new values
-
update the docs with new global setting valuessecret feature -
update the schema with new global setting valuessecret feature
@@ -219,12 +219,15 @@ JSON_ENUM_MAPPER(::winrt::Microsoft::Terminal::Settings::Model::FirstWindowPrefe | |||
|
|||
JSON_ENUM_MAPPER(::winrt::Microsoft::Terminal::Settings::Model::LaunchMode) | |||
{ | |||
JSON_MAPPINGS(5) = { | |||
JSON_MAPPINGS(8) = { |
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.
I'm a bit conflicted about this. At this point, why not use JSON_FLAG_MAPPER
? I guess we already introduced maximizedFocus
as a valid global setting option, so this would be a breaking change.
To fix this, we would have to manually handle maximizedFocus
, and that just seems like a pain to do right now (with very little benefit tbh). Could you file this as a follow-up please?
Another thing, what happens if we use one of these in the "launchMode"
global setting? Does it work as expected? We'll have to update the schema and docs for this too, right?
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.
I didn't know about JSON_FLAG_MAPPER
, I can look into that.
I haven't tested, but hypothetically if you change the global setting to one of the new options it should launch correctly (since it uses the same code path as restoring), although I don't think it would display in the settings UI properly. With that said, while the global setting could work with this, I didn't intend on publicizing that / extending that functionality.
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.
Bah, the settings editor does not like the change here with more options, I'll fix that.
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.
option one, give the user all options:
option two, let the user set any of the options in settings.json, but only show the previous options in the ui:
I'm partial to two since I really didn't intend on publicly expanding the scope of the global settings. I confirmed that the new options work if you set them in the json at least so the enterprising user would not cause the application to crash or anything.
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.
bah, I'm ok with option 2. IIRC that means that if you hit save in the ui, the setting won't be overwritten unless you actually change/interact with the setting via the ui? (mind confirming that)
If that's the case, we should be good to go. We'll just treat the extra launchMode
global setting values as a "secret feature" because the alternative is an unnecessary pain to face haha.
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.
Yes, if you hit save without interacting with the launch mode radio buttons it will preserve whatever value you put in the json.
<data name="Globals_LaunchModeMaximizedFullscreen.Content" xml:space="preserve"> | ||
<value>Maximized full screen</value> | ||
<comment>An option to choose from for the "launch mode" setting. Opens the app maximized and in full screen.</comment> | ||
</data> | ||
<data name="Globals_LaunchModeFullscreenFocus.Content" xml:space="preserve"> | ||
<value>Full screen focus</value> | ||
<comment>An option to choose from for the "launch mode" setting. Opens the app in full screen and in focus mode.</comment> | ||
</data> | ||
<data name="Globals_LaunchModeMaximizedFullscreenFocus.Content" xml:space="preserve"> | ||
<value>Maximized full screen focus</value> | ||
<comment>An option to choose from for the "launch mode" setting. Opens the app maximized in full screen and in focus mode.</comment> | ||
</data> |
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.
Do we actually need these since we're removing them in Launch.cpp?
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.
Technically this was the way that had the least amount of code. Basically the macro currently used attempts to look up every possible enum value in the localization files and so it would crash if it didn't exist. I could've written a different macro/manually write the code so it didn't try the values being filtered out. But since I added the text for the one option I was just lazy and left it in.
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.
I appreciate this actually. Thanks.
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.
Let's do it! Thanks!
@msftbot merge this in 10 minutes |
Hello @carlos-zamora! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
@@ -19,6 +19,11 @@ namespace winrt::Microsoft::Terminal::Settings::Editor::implementation | |||
|
|||
INITIALIZE_BINDABLE_ENUM_SETTING(FirstWindowPreference, FirstWindowPreference, FirstWindowPreference, L"Globals_FirstWindowPreference", L"Content"); | |||
INITIALIZE_BINDABLE_ENUM_SETTING(LaunchMode, LaunchMode, LaunchMode, L"Globals_LaunchMode", L"Content"); | |||
// More options were added to the JSON mapper when the enum was made into [Flags] | |||
// but we want to preserve the previous set of options in the UI. | |||
_LaunchModeList.RemoveAt(7); // maximizedFullscreenFocus |
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.
My only concern is that we should file a followup and reference it in the code -- otherwise we'll forget. We should get to this during the overhaul. Heck, the followup might even be "make the launch mode UI a collection of flags"
🎉 Handy links: |
This commit adds additional information to the persisted window layouts.
Also,
to work in addition to the current Toggle{Focus, Fullscreen} actions.
This adds the capability to maximize (resp restore) a window using
standard terminal actions.
This also involves hooking up a good amount of state tracking between
the terminal page and the window to see when maximize state has changed
so that it can be persisted.
The intention is that they could assist with automation (and was originally)
how I planned on persisting the state instead of augmenting the LaunchMode.
way to save the non-maximized/fullscreen size, so exiting the modes
won't restore whatever the previous size was.
References #9800
Closes #11878
Closes #11426