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
Close deleted files faster #1994
Comments
The point of offering to save again is to protect users from accidentally losing something in common use-cases. There are many things that can cause a file to be accidentally removed, in particular version control checkout changes, and renames. These are the common use-cases that Geany was designed for. So the current behaviour won't be changed. But that said a "Close and don't save" option could be added to the infobar. Pull requests are welcome. BTW Referencing the behaviour of another tool that most Geany devs don't have is not useful, describe the desired behaviour. |
It's not a blocking dialog, it's just a passive infobar, so you don't have to do anything with it. In the case the file was deleted, there are no less than 4 ways to close the file: the tab close button, the close button in the toolbar, the close menu item in the file menu, as well as Ctrl+w. If the extra step of confirming you want to lose your open document is the problem, it can be quickly dismissed using the keyboard with Alt+d.
Seems reasonable, if maybe a little dangerous. I can imagine someone accidentally clicking the wrong button in the infobar and then having a really bad day, but I'm not strongly against it if people would find it useful for their workflows. |
Agree, thats always the risk, but its the same risk as incorrectly clicking "don't save" on the normal close popup. |
Hi, I tried to describe the desired behaviour. If anything else would be needed, please let me know.
Yeah well, I had this really bad day, two days ago. I accidentally overwrote several files on my webserver because (?) the files were still open on two machines. No, I am not blaming anyone but would like to reduce that risk. |
Ok, but since you referred to another application as the "reference for a better solution" its possible that it had another behaviour.
Note that Geany does not know that the file has been deleted, and the infobar does not say that, just that it was not found. An example of a situation which will bring up that infobar is if your remote webserver filesystem loses connection. Then you probably would want to save the file, albeit in a different place, until you sorted the connection out, so the save option opens the save dialog for that reason. |
The difference is the infobar provides the notification first, and then the modal dialog confirms the action after. I could imagine a case where someone is going really quick and presses whichever keybinding/mnemonic activates the "delete this buffer" button in the infobar accidentally. Or perhaps they're in another window in front of Geany, managing the files, and temporarily moving/deleting the file knowing it's safely open in Geany, and then they go to click the Geany window to activate it and accidentally click the "delete this buffer" infobar button and lose the document. Just a couple examples, albeit far-fetched, off the top of my head. |
I thought about this and had a closer look on the behaviour of geany. You are right, it is the same or similar effort to close one unwanted file. The real difference is, when doing this with several files, that are spread among other files that should be kept in the editor. Geany does not help me to access those files quickly. I have to think which ones are affected and open them manually. For my use case (getting rid of the affected files quickly) and also for the other use case (I want to save the files, so nothing gets lost) it would be great to put the deleted files up front, one after the other and display the notification. Then the user could either close or save all of the files. What do you think? |
Agreed, but in fact Geany does not know about those files either, it only regularly tests the current file. This is to reduce the cost of regularly There was an attempt to use the GIO file monitoring which may have been able to handle more files efficiently, but it proved to be unreliable, triggering multiple times and causing the infobar to come back repeatedly. This may not neccessarily be GIOs fault since the underlying OS
Even if monitoring worked, its considered bad UI design to reorder a users tabs. Other methods of indication could be used to allow the user to find such files quickly. |
like on the sidebar in the "documents" page having a section inside it for "deleted documents"?? |
When open files are deleted from the filesystem, Geanys behaviour is not very intuitive and somehow contraproductive. It offers to save the file again and does not give me the possibility to close the document within that dialogue.
I suggest to change the dialogue to
"File was not found on the drive. Close the file and discard content?
OK (Close the tab, do NOT suggest to save it again.)
Cancel (Do noting, keep the tab open, let the user do after that whatever he wants)
Main use case:
Editing files on a remote server by FTP with Filezilla:
-Several files are stored in a temp folder.
-I can edit them with any editor
-Filezilla tracks changes and lets me update the files after changes
-When I am done, I close Filezilla and the Temp files are deleted by Filezilla.
In that case I want to get rid of the open files quickly and do not want to store them again. Why should I?
Other use case:
editing files that are stored in a cloud and have been deleted in the meantime.
Reference for a better solution:
-Notepad++
The text was updated successfully, but these errors were encountered: