-
Notifications
You must be signed in to change notification settings - Fork 124
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
add cancel button to undo unwanted save session #512
base: master
Are you sure you want to change the base?
Conversation
- Added cancel button to undo saving of items in case it was started by mistake - If none of /connector/save* endpoints were called yet, the button will just exit at saveItems. - If the connector server has been engaged, hit /connector/cancel to tell the server to undo this session - After cancel button is clicked, the connector window is hidden - Minor style tweaks to fit the cancel buttons on the same row as tags input and done button
@adomasven I wanted to have a look at one of the connector issues while a number of accessibility changes is being reviewed and this seemed like a good one. Let me know what you think! This ended up being spread across two PRs - I marked both of them as drafts to begin with to make sure it's a reasonably direction to move in. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Yeah, this is good. In the video the Done button seems to be bigger height than the other buttons and there's too much empty space where the Cancel button expands, so let's fix that and go with it. |
- place the Done and Cancel buttons in the header - minor re-styling of all buttons in the header so they look more uniform - added new svg-s for relevant buttons, deleted unused files - disclosure button will flip the up/down on each click - cancel and done button will expand on hover and change the icon for textual label - made the entire dialog a bit wider - do not set explicit height of the dialog using scrollHeight anymore, just let it expand as much as it needs unless it leaves outside of the bounds of the screen - made the dialog a flexbox so that the progress box with items can expand as much as it needs and then become scrollable if we run out of space
Yeah, the border of the button was of the wrong color and I did make the dialog a bit too wide... There were a few other smaller things with spacing that I tweaked. How is it looking now? Screen.Recording.2024-09-23.at.11.44.45.PM.movAnd I just cleaned up earlier unrelated changes and pushed these changes. One question: I added new Also, I was doing all the testing on firefox, so let me make sure everything looks right on chrome and safari. |
Chrome looks good to me now as well. Per https://github.com/zotero/safari-app-extension, do I need to be a part of the team to build and sign the safari extension? Sorry if that's an obvious question, it's been a while since I had to work with xcode. |
Don't bother trying to test on Safari for now — it's too finicky. We'll check and report back. |
That's fine. There's a PR pending with updated icons (with the zotero submodule updated) that I am waiting an OK from Dan, but it shouldn't hold this up. |
and no margin after the last visible button in header
Sounds good! Meanwhile, I added some final touches to remove unwanted spacing after buttons and to not show the "done" button unless target selector is expanded per #512 (comment). I unintentionally reverted that change before pushing yesterday. With these final tweaks, I think I can un-draft this. |
@abaevbog You should test the |
/* Make progress box scrollable if there are too many items */ | ||
display: flex; | ||
flex-direction: column; | ||
overflow-y: scroll; |
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.
This adds a permanent scrollbar on non-macOS even when there is nothing to scroll. Should be overflow-y: auto
@abaevbog One more thing. We should enable this with a Zotero feature check. The response to /ping on Zotero should include |
Do not show cancel button if the client did not return supportsSaveCancelling from /ping or if we are saving to web library.
Gotcha, so from now on, I'll use
Oh, that is a great point! Otherwise, one could have an updated connector that would try to hit I pushed to the main repo PR to return |
src/common/ui/ProgressWindow.jsx
Outdated
@@ -127,7 +127,7 @@ Zotero.UI.ProgressWindow = class ProgressWindow extends React.PureComponent { | |||
|
|||
// Check if the X button to cancel a saving process should be displayed | |||
(async () => { | |||
let notSavingToWebLibrary = await Zotero.Connector.getClientVersion(); | |||
let notSavingToWebLibrary = await Zotero.Connector.checkIsOnline(); |
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.
This issues a superfluous /ping
call to the client. The ProgressWindow should already know whether it's saving to Zotero or the server.
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.
It looks like we always try to get available collections from the client (even if there is no zotero client running) and pass the targets (which are empty in case of saving to web) to changeHeadline
which updates the state of ProgressWindow. And then, this.state.targets
is used to determine if the headline select for collections should be rendered. Isthis.state.targets
a reasonable way to determine if we are saving to desktop vs web? It does seems to work for instances that I tried, I just wasn't sure if there are times when it would not be the case.
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 think it's just this.state.targetSelectorShown
? But target selector is written by Dan.
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.
targetSelectorShown
is updated each time when the chevron is clicked, so I think it is about whether the target selector table and tags region is expanded or collapsed...
But judging by this comment as well, does it seem like the existence of targets
should imply that we fetched them from the client, while their non-existence should imply that we'll save to the server? I feel like it does... Combined with the fact that in updateFromClient
, "Saving to zotero.org" is set without any targets and "Saving to ..." is set with the targets, I am somewhat convinced that this.state.targets
== saving to the desktop client.
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.
@dstillman, correct me if I am wrong on the above though!
Instead of an extra checkOnline call
Fixed bug where an error would be thrown in the end of changeHeadline if there is no target and the header would not get set.
/connector/save*
endpoints were called yet, the button will just exit at saveItems./connector/cancel
to tell the server to undo this sessionDepends on: zotero/zotero#4694 that adds the
/connector/cancel
endpointAddresses: #301
A rough demo with the current state of
/connector/cancel
endpoint.connector_cancel.mov