I honestly don't understand why this would work any different than how it would work in Smart SVN, which if recall allowed the in place edit.
I believe the current default is not optimal. When you click on the text area, you expect to be able to type and edit the text. That is what the user naturally expects. It's a major drag that you can't. I have updated the keyboard shortcuts so that ctrl+e brings up the full editor, but that's not the quick edit (and I don't believe it's possible to assign that to shortcut key). Switching between windows is also a highly taxing and user unfriendly experience, especially when you are trying to go thru many files making quick changes in each.
I believe the following behavior would be preferred:
- Allow editing in place, without an any extra clicks to start editing, period.
- When editing in place, there are two context buttons that appears in the section inbetween the file list and the file viewer. The buttons are in effect "save edit" or "cancel edit".
- The ability to accept changes from the the head or working tree into the index, or move changes from the index to the working tree, works just like in the full editor, depending on what view is activated.
- In other words, things behave identically to the full text editor when all three views are displayed. Even though only two views will be visible in the quick edit, any changes in the invisible view will just be parked there, unsaved. The user can switch between the two views and the unsaved changes will be visible in either the index or working tree as applicable. - This state will persist until the user does something:
- Save
- Cancel
- Clicks on a different file (resolution provided below)
- Clicking elsewhere in SmartGit, minimzing, etc., has no effect on this workflow. Only when a new file viewing is to replace the existing one, via the user's explicitly choice to click on a different file, will trigger the below workflow.
- The full text editor is also still an option just like it is now, and will behave the same. If there are local unsaved changes in either the index or working tree when the full editor is invoked, they will be brought forth into the full editor, remaining in an unsaved state within the full editor.
- Once in the full editor, the user attempting to leave the full editor with unsaved changes will pop up the confirmation modal just like it does now. The user will not be allowed to bring the unsaved changes back into the quick edit.
- In effect, this means that opening up the full editor is a way for the user to delay their making a choice on saving the content or discarding it while still being allowed to view a different file -- they can spawn as many full editor windows as they want, so if they start making a quick edit, and are unsure on what they want to do in terms of saving or discarding their work, but want to view a different file, they can do so with a simple keyboard shortcut to bring up their current quick editing changes into the full editor.
From here, the main question is how to deal with the user leaving the view / clicking on a different file within the quick edit:
- In effect, clicking on a different file behaves the same as "closing" the file in the full text editor. It's natural for users to expect to be prompted what to do when that happens and there are unsaved changes. But if you really don't want a modal, and believe that clicking on a different file isn't the same as an explicit close action by the user, you can do the following:
Three modes:
1 (Default): If user clicks on a different file, the current changes are auto-saved and the next file editor is brought up. The user will be able to see the dirty status reflected immediately in the file browser.
2 (override option from preferences): When clicking on a different file and the changes are unsaved, the dialog modal will be brought up stating that clicking on a different file will close the current quick editor, and ask the user what they want to do. The dialog can have four radio options:
* Save all
* Save working tree changes only
* Save index changes only
* Discard all
- In addition, there is a checkbox that appears beneath the radio choices that says "Automatically perform my choice as the default action (can be changed in preferences).
3) (override option next to the above): Like #1 except that all the changes are discarded instead of saved.
To be very user friendly, I would recommend that on first time this workflow is triggered on a fresh install, that #2 is actually the default behavior. That will give uses the chance to immediately tune to their liking and prevent any further modals if it's not what they prefer.
I honestly don't understand why this would work any different than how it would work in Smart SVN, which if recall allowed the in place edit.
I believe the current default is not optimal. When you click on the text area, you expect to be able to type and edit the text. That is what the user naturally expects. It's a major drag that you can't. I have updated the keyboard shortcuts so that ctrl+e brings up the full editor, but that's not the quick edit (and I don't believe it's possible to assign that to shortcut key). Switching between windows is also a highly taxing and user unfriendly experience, especially when you are trying to go thru many files making quick changes in each.
I believe the following behavior would be preferred:
- Allow editing in place, without an any extra clicks to start editing, period.
- When editing in place, there are two context buttons that appears in the section inbetween the file list and the file viewer. The buttons are in effect "save edit" or "cancel edit".
- The ability to accept changes from the the head or working tree into the index, or move changes from the index to the working tree, works just like in the full editor, depending on what view is activated.
- In other words, things behave identically to the full text editor when all three views are displayed. Even though only two views will be visible in the quick edit, any changes in the invisible view will just be parked there, unsaved. The user can switch between the two views and the unsaved changes will be visible in either the index or working tree as applicable.
- This state will persist until the user does something:
- Save
- Cancel
- Clicks on a different file (resolution provided below)
- Clicking elsewhere in SmartGit, minimzing, etc., has no effect on this workflow. Only when a new file viewing is to replace the existing one, via the user's explicitly choice to click on a different file, will trigger the below workflow.
- The full text editor is also still an option just like it is now, and will behave the same. If there are local unsaved changes in either the index or working tree when the full editor is invoked, they will be brought forth into the full editor, remaining in an unsaved state within the full editor.
- Once in the full editor, the user attempting to leave the full editor with unsaved changes will pop up the confirmation modal just like it does now. The user will not be allowed to bring the unsaved changes back into the quick edit.
- In effect, this means that opening up the full editor is a way for the user to delay their making a choice on saving the content or discarding it while still being allowed to view a different file -- they can spawn as many full editor windows as they want, so if they start making a quick edit, and are unsure on what they want to do in terms of saving or discarding their work, but want to view a different file, they can do so with a simple keyboard shortcut to bring up their current quick editing changes into the full editor.
From here, the main question is how to deal with the user leaving the view / clicking on a different file within the quick edit:
- In effect, clicking on a different file behaves the same as "closing" the file in the full text editor. It's natural for users to expect to be prompted what to do when that happens and there are unsaved changes. But if you really don't want a modal, and believe that clicking on a different file isn't the same as an explicit close action by the user, you can do the following:
Three modes:
1 (Default): If user clicks on a different file, the current changes are auto-saved and the next file editor is brought up. The user will be able to see the dirty status reflected immediately in the file browser.
2 (override option from preferences): When clicking on a different file and the changes are unsaved, the dialog modal will be brought up stating that clicking on a different file will close the current quick editor, and ask the user what they want to do. The dialog can have four radio options:
* Save all
* Save working tree changes only
* Save index changes only
* Discard all
- In addition, there is a checkbox that appears beneath the radio choices that says "Automatically perform my choice as the default action (can be changed in preferences).
3) (override option next to the above): Like #1 except that all the changes are discarded instead of saved.
To be very user friendly, I would recommend that on first time this workflow is triggered on a fresh install, that #2 is actually the default behavior. That will give uses the chance to immediately tune to their liking and prevent any further modals if it's not what they prefer.