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.

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

Adapt the SaveVersionDialog text field to use ctr+s for accept #268

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

tom95
Copy link
Collaborator

@tom95 tom95 commented Jun 7, 2020

While this change works, I had to drop the method updateMessageFromViews as it would have send the accept message to the text field on cancel as well. Sadly, I did not understand what the idea behind updateMessageFromViews was, @j4yk could you maybe explain? I'm a bit afraid this removes functionality I was not aware of.

@tom95
Copy link
Collaborator Author

tom95 commented Jun 7, 2020

Oh, how could that change in the postscript have come to be? I created this commit using the latest develop version of Squot and the commit dialog did not show changes to the postscript being staged.

@j4yk
Copy link
Collaborator

j4yk commented Jun 7, 2020

updateMessageFromViews is there so you need not accept the text in the box first to update it in the model. It means you can type the text, not press ctrl+s, and then click commit and the typed text will be accepted.

@j4yk
Copy link
Collaborator

j4yk commented Jun 7, 2020

@LinqLover also has run into a postscript issue in #258 and I have as well, as can be seen here: 9254dfd, cb398d1

But I did not find the cause yet, at least if Monticello-ct.715 is not the only cause. Please open a separate issue and check the following: does the package currently have a postscript in your image (before the commit, after the commit)?

@j4yk
Copy link
Collaborator

j4yk commented Jun 7, 2020

Now on to the actual pull request: do you want to finish the commit by pressing ctrl+s in the text field, or is it something different? Because if you wanted to "double confirm" the message (first ctrl+s, then press commit) instead, I would not like this.

'src\/Squit.package' : #SquotCypressCodeSerializer,
'src\/BaselineOfSquot.package' : #SquotCypressCodeSerializer,
'src\/SquotTonel-Core.package' : #SquotCypressCodeSerializer,
'src\/SquotTonel-Tests.package' : #SquotCypressCodeSerializer
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you have a different version of STON than I have?

@@ -0,0 +1,5 @@
accessing
message: anObject notifying: aController
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since aController is unused here, why change from message: to message:notifying:?

"actionCommit" : "fn 4/11/2017 16:01",
"activateNodeCommandLabel" : "jr 4/7/2019 22:30",
"browseOtherEdition" : "jr 6/6/2020 01:04",
"browseOtherEditionLabel" : "jr 6/6/2020 00:48",
"buildButtonBar:" : "jr 11/18/2018 01:39",
"buildDiffPane:" : "jr 11/18/2018 01:33",
"cancel" : "jr 11/18/2018 00:44",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text was updated even on cancel, so the text could be saved for later.
Without your change, one can start a commit, write a message, then notice a bug in the diff, cancel, fix the code, press commit again, and the previously typed message is filled in automatically.
That logic is not in the dialog class, but in the SquotWorkingCopy or SquotInteractiveSaveOperation.

@@ -5,7 +5,8 @@ widgetSpecs: builder
name: 'message for the new version';
model: self;
getText: #message;
setText: #message:;
setText: #message:notifying:;
askBeforeDiscardingEdits: true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It takes me too long to check this myself in Morphic: does it prevent the commit dialog from closing if you press cancel? If so, how?

Copy link
Collaborator

@j4yk j4yk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check and make sure that

  1. the message is still remembered even if you close or cancel the dialog,
  2. pressing ctrl+s is equivalent to hitting the commit button,
  3. that pressing ctrl+s is an optional way to accept, not a required one. That means you must still be able to hit commit and the text that is currently in the box will be taken, even though it may not have been updated in the model yet.

Also think whether this is really something the user will expect: in workspaces you can press accept to just remember the text for later, but here it will actually start a transaction on the repository and close your window.

@tom95
Copy link
Collaborator Author

tom95 commented Jun 7, 2020

Hey Jakob, thank you for that detailed list of requirements, that's exactly what I was looking for :) I already kinda suspected that it was meant to persist the text across invocations but didn't manage to follow the control/data flow to make that happen.

The intent was to have a keyboard-based way to finish a commit, so the behavior in my image right now is that I can either press the "Accept" button or hit ctrl+s to confirm and perform the transaction. This is consistent with all other dialog windows in Squeak where accept also means confirm. I suppose in this way you can also look at editing a method as a transaction.

I will update the PR in a bit to address all issues. Sorry that it looks a bit messy, I only looked at the GitBrowser's diff before placing the PR and didn't notice the extra changes.

does the package currently have a postscript in your image (before the commit, after the commit)?

Could you tell me how to best find the postscript in my image? Would I inspect the artifacts in my the GitBrowser at the respective commits? The postload for Squot.core contains the script in both this PR's commit and its parent.

@j4yk
Copy link
Collaborator

j4yk commented Jun 7, 2020

"Loaded" scripts you find by right-clicking on the package in the object list in the Git Browser (bottom right). Or in the Monticello browser (working copy browser) select the package and use the Scripts button.

Historical scripts you can find by selecting the commit, in the objects list choose "Explore" in the package in question, select the #artifact item in the explorer and inspect self shadowOfTrackedObject (it will trigger the lazy loading of the files). You should get an inspector on a SquotPackageShadow, where you can inspect the MCSnapshot and see whether it contains an MCPostscriptDefinition.

@j4yk
Copy link
Collaborator

j4yk commented Jun 7, 2020

...or you do it much simpler: select the commit, right-click the package, and just choose "Browse edition in selected version" :-) In the Monticello snapshot browser you will see the scripts when you select nothing in the panes above.

@tom95
Copy link
Collaborator Author

tom95 commented Jun 7, 2020

Alright I believe I got the behavior correct in all cases now. Instead of cancel, we now wait for windowIsClosing to also catch the user dismissing the window without clicking the Cancel button.

I changed the spec's setter selector to acceptMessage: to make it clear that this will also commit the transaction. #message: is still used by the setup code that restores the previous message.

How should I got about the inadvertent changes? Just reset them and do a cleanup commit? I am also not sure what happened on the STON output, it should be the latest version from the squeak-ston repo.

@tom95
Copy link
Collaborator Author

tom95 commented Jun 7, 2020

...and the askBeforeDiscardingEdits: false is apparently a somewhat quirky way of telling the widget that we do not care about the changed state when it comes to accepting. Without setting this flag to false using an already stored string in the model cannot be accepted, e.g. when we come up with a previous commit message and the user just wants to accept without doing further changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants