There is many instances / use case where the current default "file changed" process is broken, report false positive or steal focus for the wrong reasons. This bug describe a few scenarios when (I think) can be considered a bug, or at least usability nightmare. Reproducible: Always Steps to Reproduce: Scenario 1: 1. Stash file in git from the kate embedded terminal 2. Pull/Merge something 3. stash pop Result: a popup steal the focus, {press escape}, do the merge, stash pop. An other popup steal focus, again. All file touched by the stash are marked changed, even if they are not (anymore). If a file touched by the operations are opened using the project plugin or document list, it popup an other popup, even if the file was never loaded during the session. (I know you can reload all, it is not my point) Scenario 2: 1. Open 2 Kate instances (2 window, 2 process) with the Kate project plugin enabled 2. Change something in one Result: The other window steal focus because the file changed. Even if it is not the same project!!! Solution: * Stop using popups for that and use the embedded widget and make the document read only while a decision have to be made. * Do not watch file that have never been used locally during the current session. If they change externally, then be it, it pose no problems. * Hide the reload popup if a new update bring the document back to the previous state * Reload file in background if the content is already saved for that file * Never steal focus * I don't think application based on keyboard should use popups, a mouse based control that steal focus by design.
You are right, there are room for improvements on this frontier. Still, stuff like "auto-reload in background" are no good idea. I want to keep my text as is until I review if the change on disk is what I want. An inline notification seems like the best idea to do. Still there are then other questions, like how the interaction between kate and part should happen, to close all this inline messages if you e.g. decide to discard all in the application.
Would it be possible to have a checkable QAction to enable or disable automatic reloading of files that have never been touched during the session? (Fake) Usecase: I am at work, I work on a big project. I open a project with about 200 files, but I only care about a subset of these file. There is over 10 peoples working on this project committing atomic commits about 75+ time everyday. It happen we have a deadline today and I pull the tree every 30 minutes or so. In that case, I would not care a at all about file change, I pulled simply to have the latest codebase to test against. Having to think about the file changed dialog is: * Not necessary for the current workflow, and in usability, adding unnecessary step is bad, force the brain to context switch for nothing * Redundant, git already warn you about the files you need to take a look at or will just cancel the pull So, in case you make the document read-only until the changes are accepted, it force you to deal with issues you currently don't care about. At the same time, in some cases, like a project where I am the maintainer / product owner, I would tend to agree with you, I do want to review the changes one by one. However, I am not sure it is Kate job to do so. In an other case, I never, ever want Kate to automagically reload the file I am currently viewing without my permission. So, it is a mixed bag of pro and cons for this one. It is why I think having the (KAction) option to reload file never used and possibly all other file except the current one would be a good idea. ____ Also, the reason why I marked this as a bug instead of wish, is because when the project plugin is enabled and you have 2 Kate instances running, it really is. They just fight each other to death.
The popup has caused me issues as well. There have been times where I was working within a terminal panel from within Kate, running a command that changed an open file. Not expecting the popup, I continued typing the next command, only to have the box steal focus and have my keystrokes trigger an unwanted, irreversible action. In one case, this resulted in some data loss. This is definitely not good behavior at all. Moving away from a popup to some embedded widget is ideal, I think, but simply deferring the popup until the user explicitly refocuses the pane containing the file in question would help, I think.
This happened to me the other day - editing a config file, pop-ups, stolen focus, hopeless confusion about what would actually happen if I pressed any particular action button. The dialogue seemed very unclear to me, as if written in an unfamiliar formal logical system, involving mind-reading and foreign languages. One really should not have to think that hard. I agree with Travis Evans, "definitely not good behavior at all". I opted to examine differences (I actually wanted to see what a gui had done to the config file I was looking at). This dropped me into temp file of little relevance, and lost contact with the file I was actually editing, without making it clear what it had done. Come on, it isn't rocket science, is it? Gedit seems to do better (am I allowed to say?); clear, intuitive, without interfering in control.
Git commit 0e299055c5c89f76a2301a2dde41214216e6066a by Dominik Haumann. Committed on 07/09/2016 at 20:34. Pushed by dhaumann into branch 'master'. Use non-modal message widget for externally modified file notifications No more modal dialogs for externally modified changes that can acidentally be pressed while typing. For Kate, nothing changes if you have "[x] Warn about files modified by foreign processes" enabled. Differential Revision: D2700 Fixed-In: KDE Frameworks 5.27 Related: bug 351932, bug 353712 M +0 -1 src/CMakeLists.txt M +47 -123 src/dialogs/katedialogs.cpp M +12 -12 src/dialogs/katedialogs.h M +62 -70 src/document/katedocument.cpp M +9 -5 src/document/katedocument.h M +0 -8 src/view/kateviewinternal.cpp http://commits.kde.org/ktexteditor/0e299055c5c89f76a2301a2dde41214216e6066a
Thanks! I am not at Akademy this year, but I will buy you guys a beer eventually.
Better first try whether it works as you expect :-) See also: https://kate-editor.org/2016/09/07/embedded-notifications-for-externally-modified-files/