SUMMARY Lately (maybe up to a year ago), kate was changed such that if a file changes on filesystem (and the change is not between two git commits), it does not show the modal KateMwModOnHdDialog anymore, but instead a sort of "popup" on the top of the text editing window. I think this is a negative change for the following reasons: 1. a user will notice the change only when opening the file (as in, selecting it as the current buffer, even if it's already opened). You don't get an overview over what has changed, or you will only notice a longer time later. 2. this does not block editing. You can continue editing and ignore this popup, making the situation worse, or unknowingly overwriting the version on filesystem by hitting the save file shortcut. 3. the popup has a button that makes a permanent choice; dangerous, and requires the user to search through the preferences dialog to disable it again (bad UX), from what I understand. 4. the popup's appearance and disappearance is animated, which is slow and moves the text around, which is irritating. 5. what do you do if you intentionally changed the state on filesystem, and want to either keep or reload all changed files? I guess you could manually go to each file, or just to reload all files, but still worse than the old state. While the old dialog was maybe not the best UI around, it was still better than the current behavior. I'm not sure when this happened; I think it's due to ktexteditor, since the KateMwModOnHdDialog class is still in the kate source code, and just reverting to an old kate commit didn't restore the behavior. Bisecting is a bit hard because of all the interdependencies. STEPS TO REPRODUCE 1. load a kate session (which is using the git project plugin I guess) 2. open 2 files (and optionally open to a third file) 3. change the two files using some other program OBSERVED RESULT When focusing the editor again, nothing happens until you navigate back to one of the changed files. If you do, an animated popup appears on the top of the editing window, which asks you whether to reload. You can ignore the popup. EXPECTED RESULT Focusing kate again shows a modal dialog that lists the changed files (no matter which file is currently focused), and gives options to reload and overwrite the files. Editing is blocked.
FWIW I'm also not super happy with the new UI, but I didn't really like the old UI either. Might need VDG input to come up with something better.
You should still get a dialog when you enable in Kate's general settings the option [x] Warn about files modified by foreign processes, see: https://docs.kde.org/stable5/en/applications/kate/configuring-kate-configdialog.html Can you please try again?
> [x] Warn about files modified by foreign processes Of course this option was enabled in all of my tests. I suppose if it were disabled, the new "popup" would not appear at all. > I'm also not super happy with the new UI, but I didn't really like the old UI either. Yes, the old UI wasn't too great. But it was pretty functional. My claim is that it had the following 2 non-cosmetic advantages: 1. A modal dialog that forces the user to intervene (and prevents making it worse) 2. Handling all changed files at once As far as non-cosmetic goes, I really dislike the way the "popup" is animated and displaces the text.
Also, I'm fairly sure it sometimes doesn't even show the "popup" when the file has changed, and simply reloads it (despite "Warn about files modified by foreign processes" being enabled). That's quite scary. A lot of times, the buffer contents are my backup. (Yes, you could argue how it shouldn't be and how I'm doing it wrong, but anyone who says that is wrong.)
The old use did lead to constant modal dialogs that distract if you use a proper version control system. On each git stash or similar you needed to tend to dialogs even if you didn't care. Therefore I am very opposed to go back to the old way. If somebody comes up with a new way to handle file changed stuff in a reasonable non-distracting manner, we can take a look at that.
> The old use did lead to constant modal dialogs that distract if you use a proper version control system. So you're saying that for example I don't know how to use git? > On each git stash or similar you needed to tend to dialogs even if you didn't care. It already ignores changes that are contained in git, so this didn't happen in the old way. But I disagreed even with this change. Besides, you can configure it to autoreload. If I configure my editor not to autoreload, I don't want it to autoreload. In the case of a "git reset --hard" the kate buffers are my last backup too. I'm still on a ~1 year old kate version because of this. It's getting annoying. I've lost code to kate buffers being somehow discarded far too often already.
> So you're saying that for example I don't know how to use git? I only stated a scenario for which the old system did lead to irritations, as an example. The same annoyance is there if you have files open that are constantly appended to, like log files. As said, I can't see that the old behavior was better and I think we do really put a lot of effort into avoiding data loss. You could have clicked the old dialog away without care, now you can ignore the info bubble, yes. I still think the current way is superior in many workflows and don't will bring the old behavior back, sorry. If there is some draft of a new way to signal that changes that is still non-intrusive per default and somebody is stepping up to implement that, I am open for such proposals.
> I only stated a scenario for which the old system did lead to irritations, as an example. Fine, fine. Please note that I stated scenarios for which the old system was superior. > As said, I can't see that the old behavior was better I can't see how the new behavior is better. > The same annoyance is there if you have files open that are constantly appended to, like log files. I'm sure it's great when kate constantly auto-reloads an appended file (for which it has to read and syntax highlight the entire file all over again).
> I'm sure it's great when kate constantly auto-reloads an appended file (for which it has to read and syntax highlight the entire file all over again). It actually really is. And is a feature I rely on for e.g when debugging using the AST in a file dumped by the compiler.. Since no one else complained in more than 2 years and the change was intentional, I see no reason why we should keep the bug open. Potential improvements or alternatives can be discussed in a new bug
> It actually really is. And is a feature I rely on for e.g when debugging using the AST in a file dumped by the compiler.. That's pretty inefficient, you'd be better off with a "tail" command in the terminal. But I suppose seeing an obscure use-case is much better than not incompetently destroying the editor's good behavior as it was designed and implemented years ago, when I thought kate would be a good choice. Really sad. I can stay on my 2018 build until it breaks, then maybe switch to sublime. Thanks for everything.
Trying to be a bit constructive ;) Point 1) about not noticing the changed files before navigating to the effected files, is something that we could have a look at. I find myself doing "Reload All" a bit too often to make sure I have up to date content in the loaded files. Searching in Project / Folder will give you old data until you reload... That said I do not want to go back to the previous dialog. Maybe we could make sure that we get a KMessageWidget immediately in the active view(s) that could contain a "Reload All" button or something similar?
> That's pretty inefficient, you'd be better off with a "tail" command in the terminal That reads as if you didn't understand what I was saying. At all. Nevermind though. The *good* behavior you say had problems as noted above. Going in the reverse direction isn't possible for various reasons such as no one seems to be interested to work on it and is satisfied by the existing behavior. This is the gist of everything we do in kate, we ourselves are motivated to implement something and then do it but if there is no interest, no one does it. And mind you, we work on it for free, you don't pay us to implement things the way you want them to be. Anyways, it seems that you are not satisfied, and I assume you are very efficient and competent in everything you do, maybe you can show us a way which is better, which doesn't have the old problems and the problems from the new popup. And since you seem to like Kate, maybe you will show this way via a patch that improves Kate and and as a benefit move forward to 2022 and stay on Kate.
(In reply to Waqar Ahmed from comment #12) > > That's pretty inefficient, you'd be better off with a "tail" command in the terminal > > That reads as if you didn't understand what I was saying. At all. Nevermind > though. > > The *good* behavior you say had problems as noted above. Going in the The new behavior has several problems as well. > reverse direction isn't possible for various reasons such as no one seems to > be interested to work on it and is satisfied by the existing behavior. This > is the gist of everything we do in kate, we ourselves are motivated to > implement something and then do it but if there is no interest, no one does > it. And mind you, we work on it for free, you don't pay us to implement > things the way you want them to be. It's more like someone trashed the old behavior as it was designed. > Anyways, it seems that you are not satisfied, and I assume you are very > efficient and competent in everything you do, maybe you can show us a way > which is better, which doesn't have the old problems and the problems from > the new popup. And since you seem to like Kate, maybe you will show this way > via a patch that improves Kate and and as a benefit move forward to 2022 and > stay on Kate. My tone sure was off, but whatever. I can only say that I do prefer the clunky old dialog over the new UI, both in terms of functionality and usability. I just tested a newer version of kate (22.08.2) and changed opened files externally under various circumstances. I didn't encounter the new UI, which is weird. Instead it showed the old file modification dialog in some situations, while it strangely just hard reloaded automatically in other situations. Does that mean you returned to the old dialog? I also remember trying to fix some file modification bugs. I found some problems (including race conditions), which eventually just made me disable the code that tries to filter "false positive" modification notifications. Noisier, but removed some even more annoying bugs that sometimes happened.
> I can only say that I do prefer the clunky old dialog over the new UI, both in terms of functionality and usability. *You* do, but not everyone. > I just tested a newer version of kate (22.08.2) There is no such version, but whatever. > and changed opened files externally under various circumstances. I didn't encounter the new UI, which is weird. Instead it showed the old file modification dialog in some situations, while it strangely just hard reloaded automatically in other situations. Does that mean you returned to the old dialog? Idk what the dialog you are seeing. Perhaps you have the setting "Use a dialog for externally modified files on". > I also remember trying to fix some file modification bugs. I found some problems (including race conditions), which eventually just made me disable the code that tries to filter "false positive" modification notifications. Noisier, but removed some even more annoying bugs that sometimes happened. Yep sure, though there was never a PR so whatever theoretical improvements you made benefited no one or improved kate but what does that matter, eh?, but whatever.
(In reply to Waqar Ahmed from comment #14) > > I can only say that I do prefer the clunky old dialog over the new UI, both in terms of functionality and usability. > > *You* do, but not everyone. *You* like the new UI, but not everyone, but whatever. > > I just tested a newer version of kate (22.08.2) > > There is no such version, but whatever. Actually 21.08.2, but whatever. > > and changed opened files externally under various circumstances. I didn't encounter the new UI, which is weird. Instead it showed the old file modification dialog in some situations, while it strangely just hard reloaded automatically in other situations. Does that mean you returned to the old dialog? > > Idk what the dialog you are seeing. Perhaps you have the setting "Use a > dialog for externally modified files on". Probably? But I didn't get the new UI even when I switched that off. Maybe the new UI was removed? You don't seem to know your software, but whatever. > > I also remember trying to fix some file modification bugs. I found some problems (including race conditions), which eventually just made me disable the code that tries to filter "false positive" modification notifications. Noisier, but removed some even more annoying bugs that sometimes happened. > > Yep sure, though there was never a PR so whatever theoretical improvements > you made benefited no one or improved kate but what does that matter, eh?, > but whatever. Thanks for the encouragement, but whatever. I actually reported this as #388186. As I said, my patch would be unacceptable. Fixing the problem correctly would have required major changes.
Sorry that you can't get your wish, hope you enjoy some other editor :)
(In reply to Waqar Ahmed from comment #16) > Sorry that you can't get your wish, hope you enjoy some other editor :) Switching to another editor would be a good idea in every case, seeing how KDE is bitrotting in general (and I already had to give up on at least one or two other KDE applications). So much for assholing back. The really troublesome thing is that kate 21.08.2 works closer to how I want it to behave again (and doesn't have the behavior you defended). Thanks for the confusion I guess, if you wanted to troll you did it right.
By all means. Though read what I wrote above again. I asked you for a better solution, a solution which satisfies both what you want and at the same time satisfies the reasons for which the new UI was introduced. This has been said in this thread multiple times which you have been ignoring because it seems more like you only care if things work your way.
(In reply to Waqar Ahmed from comment #18) > By all means. Though read what I wrote above again. I asked you for a better > solution, a solution which satisfies both what you want and at the same time > satisfies the reasons for which the new UI was introduced. This has been > said in this thread multiple times which you have been ignoring because it > seems more like you only care if things work your way. Oh, I understand. All what was missing was a compromise of the old and new GUI (even though the new GUI seems to be gone now)? Yes, the modal dialog wasn't very elegant. But it did require the user to absolutely make a choice where a choice was needed. Where the new GUI failed was that it made the user notification and decision per-document. There's even a third-party comment in this quite audience-limited bug report that complained that he has to use "reload all" too often with the "new" (old?) behavior. Obviously there is a need to show some sort of summary of which files have changed. I've made my position about this quite clear: something needs to show an overview over EVERYTHING that has changed, and the "new" (old?) GUI just can't achieve that. So I will claim that it's up to you to come up with a GUI that unifies both conventions. Don't get me wrong, I think modal dialogs are Wrong in most cases. With fright I look at websites which come up with modal dialogs, because they want your agreement to spy on you or some shit. But in this case, it the question is: discard the data in your text editor buffer or not? I do think that's justified to show a modal dialog in this case. On the other hand, the per-document checkboxes are rather weird. I didn't claim there isn't potential for improvement here. Ready to hear your suggestions.
Does not checking the following option under "behavior" give you a dialog with list of all files always? Use a dialog for externally modified files
(In reply to Waqar Ahmed from comment #20) > Does not checking the following option under "behavior" give you a dialog > with list of all files always? > > Use a dialog for externally modified files Yes, this what I found out. Apparently it didn't use to be this way. What I am _majorly_ confused about is that I didn't see the "new" UI anywhere. Maybe my tests missed it or something. I'll try to see what using a newer kate release will turn up. Make no mistake, I think the old dialog wasn't perfect. It's just that the new UI (which I haven't seen in a while...) isn't perfect either, but, in practical terms, was worse.
> What I am _majorly_ confused about is that I didn't see the "new" UI anywhere Not exactly sure about this, but maybe when you have the dialog enabled you don't get per doc notifications. The per doc notifications activate on focusing the view, but if you reload everything there will be no notification since the doc has already been reloaded.
Since a few days I'm extensively working with kate or kwrite (internal krusader editor). Today I obeyed silent update of the editor window contents when the file being edited is changed from outside (e.g. git operation). Since I - with a long 'career' of using these editors - was highly alarmed about this loss of work (not really, I could retrieve it again), I investigated. Long story short: It seems that the behaviour has simply become unreliable. Sometimes the editor window is silently updated, sometimes not. Probably related to OS flavor. The problems occur on a debian bullseye based distro (MX Linux). The expected behaviour has never been a problem using Linux Mint 20.4 (and before). This one is based on Ubuntu focal. Because I know about correct operation on Mint 20.4, I decided to download two .deb files from the ubuntu focal repository: - kate5-data_19.12.3-0ubuntu1_all.deb - kate_19.12.3-0ubuntu1_amd64.deb I was a bit surprised that no dependency problems occurred. The silent editor window update is occurring here as well. Finally I restored the original condition. I now also rememered that upon an editing session last week, no problems occurred (no silent updates). Somehow curious...