Version: 2.5.8 (using KDE KDE 3.5.8) Installed from: Fedora RPMs OS: Linux I've got /var/log/yum.log open in Kate. I switched to konsole and did a yum update. Using the KDE panel I click on the 'log out' applet. Kate blocks the log out to let me know that yum.log was updated - what use is that?
*** Bug 152221 has been marked as a duplicate of this bug. ***
Ok, so this message was not of any use to you. However, I don't see what could reasonably be done about this. 1) kate can't know that you knew the file was about to be modified 2) kate can't know that you don't care about the modification of this particular opened file 3) kate can't just assume that on logging out / exiting kate you no longer care about external changes in any of the open files If you can state explicit rules, where / when / how kate could be smarter, please do. Otherwise, I think this is going to be a WONTFIX.
...or a configuration switch?
...and that switch would control...? The only possible switch would be: [ ] do not warn about external changes But then, you have to add some more options -- what to do if external changes occur -- reload, ignore, overwrite? I doubt there is anything useful in having such options. The only thing I see it could be improved are warning about read-only files. Kate currently shows inappropriate info dialog: * reload -- could be done * overwrite -- impossible since it is read-only file * ignore -- could be done, but since user cannot do anything about it anyway this leaves only "reload"
I just had an idea - it could be a useful kate feature anyway! On screen display just like thunderbird. 1[ ] ignore external changes on log out / shut down 2[ ] use on-screen display to show external changes on log out / shut down The second option would only be enabled if the first one was checked, just like thunderbird, indicating what files are being ignored. * reloading the document would be pointless - the user is logging out; kate is about to exit * overwriting the document without notifying the user could be potentially disastrous * ignoring the file change modifications is what the check box is for Or as an alternative / addition? 3[ ] use on-screen display to show external changes Might be useful anyway? The user could click on the on-screen display before it disappeared, blocking logout/shutdown. My aim would be to change kate from being blocking to being non-blocking wrt logout/shutdown.
Maybe first of all some thoughts: a) it is really a good way to spot a problem, generalize it, and then find a solution to general problem b) solution should be universal (see below) Let's deal with (b) first. > The user could click on the on-screen display before it disappeared, > blocking logout/shutdown. Bad UI design -- think: handicapped people. > I just had an idea - it could be a useful kate feature anyway! On screen > display just like thunderbird. OSD is just a way of displaying data, it is not solution per se, so it would be good to leave it out for a while. > 1[ ] ignore external changes on log out / shut down > * reloading the document would be pointless - the user is logging out; kate > is about to exit > * overwriting the document without notifying the user could be potentially > disastrous Ignoring could be disastrous as well. Let's take a look: app A --> data <-- app B I cannot tell which app is more important. But you see here Kate is A, thus Kate is less important and data should be modified as B likes it. > * ignoring the file change modifications is what the check box is for And how this design works with modified file in Kate and modified externally at the same time (while logging out?). I agree with you that it would be nice to have question-free shutdown solution but it should be "smart" and error-prone. I have an idea how to solve it 100% error-prone and with respect to data safety but it takes two more reports -- first autobackup feature and second session snapshot on shutdown.
Autobackup report: https://bugs.kde.org/show_bug.cgi?id=103234 Session snapshot on shutdown: The idea is you cannot tell if the shutdown is just a regular shutdown or emergency shutdown (and in this case it would be better to do everything automatically). So the safer assumption is -- do everything automatically _always_. Kate could do this by closing all not modified files (by Kate, or by any externall app) and for the rest making snapshots: * original content (what is on the disk) * content after open/last save * the current content from the editor No questions asked, Kate quits. On the next run however Kate restores those snapshot and then asks what to do. So the idea is not to omit questions and just blindly go with one option (because it could be the case the auto-answer is not good) but to postpone all questions when the user has time to answer those questions. With autobackup feature it would be easier to do, since autobackup requires crash recovery, so partially this is the same design.
I miss hibernate support - it hasn't worked for me in some time. What I think you're aiming for is kate hibernation. When hibernate worked for me I found it really useful to be able to roll back the document (with undo) past the last hibernate. I reported a similar problem with the gnome crash handler displaying in response to an application crash on logout - it too should hibernate and resume user interaction on next login, instead of displaying briefly before the X-session shuts down.
Philip, however I am not familiar with any app with hibernate feature, but judging from the its name this would be it. This would solve your problem and give all users powerful tool.
Nice ideas, but that should go as enhancement. The current method is suboptimal, but avoids data-loss in worst case.
I still like the current behavior, it avoids data loss. All proposed solutions are really out of scope for such a minor issue (for some). To have a full "snapshot" system only to avoid this one dialog is really not maintainable, sorry.