flameshot icon indicating copy to clipboard operation
flameshot copied to clipboard

Its very easy to lose your work

Open majkinetor opened this issue 3 years ago • 16 comments

I can dedicate 10 minutes adding numbers, text etc, just so that one ESC extra or even ctrl + c can close everything without an option to restore on screen what was last visible.

This is major design mistake. I suggest doing any of bellow things:

  1. An option to prevent closing the editor. Add explicit [x] somewhere, maybe next to the ToolSettings.
  2. An option to restore last view after you accidentally exited. Right clik on tray and then Reopen last one. Even better, keep a list of several recent so we can recall any of them.

majkinetor avatar Nov 09 '21 12:11 majkinetor

I have been contemplating option 2 for a while now.

Similar to greenshot where to can save it in a resumable format.

borgmanJeremy avatar Nov 09 '21 13:11 borgmanJeremy

I think it would be great to be able to save and resume progress to/from an SVG file. Or maybe an SVG-based spinoff if we need custom functionality.

veracioux avatar Nov 09 '21 13:11 veracioux

I have been contemplating option 2 for a while now. I think it would be great to be able to save and resume progress to/from an SVG file

SVG sounds ideal... It doesn't really matter how it is stored locally as long as you can restore it.

How about we have option 1 ASAP and you can ruminate about option 2 as long as you need. Option 1 will certainly prevent losing work by accident. It happens to me at least once a day.

majkinetor avatar Nov 09 '21 14:11 majkinetor

@majkinetor I can relate. I think we should implement the following strategy as a first resort:

  1. If no selection is made and if no edits were made, Esc will close the GUI normally.
  2. If the user has made some edits, pressing Esc will show a confirmation dialog
  3. The GUI can be closed without confirmation using the close button (which already exists) or using the shortcut that the user has bound to that action (by default Ctrl+Q, not easy to hit by accident)

I am against adding a config option, because it is less discoverable and bloats the example config file.

veracioux avatar Nov 09 '21 14:11 veracioux

If no selection is made and if no edits were made, Esc will close the GUI normally.

Selection is not important, you can quickly recreate it, so I would look just for existence of objects.

If the user has made some edits, pressing Esc will show a confirmation dialog

As an option, confirm makes most sense. Esc on confirmation should cancel confirmation. Enter should confirm. ESC+Enter by accident is not likely at all.

The GUI can be closed without confirmation using the close button (which already exists) or using the shortcut that the user has bound to that action (by default Ctrl+Q, not easy to hit by accident)

I can't see the already existing button. Shortcut should be typical CTRL+W (closes tabs and windows almost everywhere).

I am against adding a config option, because it is less discoverable and bloats the example config file.

I was thinking about general configuration options such as:

  • [x] Confirm exit if there are user created objects

which is on by default. With it we don't need GUI closure option, it could always be there and work as you suggested.

majkinetor avatar Nov 09 '21 14:11 majkinetor

@majkinetor

I can't see the already existing button. Shortcut should be typical CTRL+W (closes tabs and windows almost everywhere).

The button is shown only when a selection is active (looks like an X). The shortcut should work independently of the button, even with no selection. If this is not true for you then it's likely because you've disabled the button and/or shortcut in the config. If you are using version 0.10.1 or earlier, the shortcut may not work when the button is disabled in the config. This has been fixed in the recent development versions.

Ctrl+Q is also very typical for a "quit" action. I would be fine with either shortcut, but since Ctrl+Q has been a default for a long time, I vote to preserve it and prevent confusing existing users.

I was thinking about general configuration options such as:

I think this is unnecessary and I vote against it.

Agree with the remaining points.

veracioux avatar Nov 09 '21 15:11 veracioux

The button is shown only when a selection is active (looks like an X).

I can't see it on v10.0.1:

details image

The shortcut should work independently of the button, even with no selection. If this is not true for you then it's likely because you've disabled the button and/or shortcut in the config.

My config

detailsimage

Can't see anything wrong with it.

majkinetor avatar Nov 09 '21 15:11 majkinetor

@majkinetor These settings are in the "Shortcuts" and "Interface" tabs of the configuration window.

veracioux avatar Nov 09 '21 16:11 veracioux

Yeah, my bad. Thx.

majkinetor avatar Nov 09 '21 16:11 majkinetor

Sorry I'm a bit late to the party.

If no selection is made and if no edits were made, Esc will close the GUI normally.

Selection is not important, you can quickly recreate it, so I would look just for existence of objects.

I agree with this. selection area is not important, but the objects can be.

I can't see the already existing button.

image image

Shortcut should be typical CTRL+W (closes tabs and windows almost everywhere).

Well, the "quit" is generally bound to Ctrl+q (e.g Firefox, Vivaldi, LibreOffice, Kate, Gimp, Inkscape), plus the Ctrl+q is already implemented.

In general I would suggest going with SVG file approach. This would be also useful as we can use the same code and functions to save the screenshot as SVG, plus it is loss-less.

mmahmoudian avatar Nov 10 '21 13:11 mmahmoudian

The same problem is with the "copy the selection into the clipboard" button - it should not turn off the editor without the chance to restore it. The action is called "copy the selection into the clipboard", not "copy the selection and quit". Very misleading.

szymonk211 avatar Dec 03 '21 07:12 szymonk211

Indeed. It happened to me that I misclicked it, especially with dynamic button behavior.

I prefer that it turns off the editor, as it is obviously the last thing one would do intentionally. With option to return previous editing session I think it shouldn't be any changes (except in the tooltip as @szymonk211 noted).

majkinetor avatar Dec 03 '21 09:12 majkinetor

I just noticed now that ESC button shortcut is grayed out and can not be disabled:

image

This is very weird design choice. Why not making it customizable and/or removable? This issue could be quickly solved that way - one can remove this hotkey and rely on close button to finish editing.

majkinetor avatar Jun 23 '22 13:06 majkinetor

As a 30-year user of vi/vim and bindings in every IDE, this catches me ALL... THE... TIME... It's just too easy to hit escape and lose everything. Option #2 is definitely the ideal : I'd actually like to be able to cancel with Esc, but would like to be able to say 'doh' and recover it. In the meantime, as a workaround, I'm using bettertouchtool on Macos to capture the escape key and assign it to nothing when Process Name == Flameshot. I've been using the same trick to prevent the Commit dialog for Git in Intellij closing on my for years now.

rhubarb avatar Sep 29 '23 07:09 rhubarb

Ah god-damn, I use that trick all the time, and it didn't occur to me to use it here. Thanks @rhubarb .

BTW, I am still in the this catches me ALL... THE... TIME... camp

majkinetor avatar Sep 29 '23 14:09 majkinetor

A 'reopen' of last screenshot, including ability to manipulate the custom objects, would be a huge improvement:

  • for those who accidently pressed ESC
  • for those (like me) who prefer to copy to clipboard and than to realize that the next application can't import the image via clipboard (the workaround to open an app who can import via clipboard and save from there is pain).

crose-project avatar Feb 03 '24 14:02 crose-project