Actually, I think it would be a good idea to remove the "Cancel" button entirely (or technically, rather remove the "Ignore" button, but relabel Cancel to Ignore at the same time).

I know there is a subtle difference between Ignore and Cancel, but personally I never figured this out before reading the explanation of the difference in bug #119787. Is the differentiation between Ignore and Cancel really important enough to warrant the confusion it brings?

Thomas, but there is no Cancel button, only Ignore.

> Is the differentiation between Ignore and Cancel really important enough to
> warrant the confusion it brings? 

In that case Cancel would be bad since what user "cancels"? Ignore is appropriate here, but if I am reading you correctly this is what you wished for, right?

There should be only three actions:
* overwrite
* ignore
* reload

But exactly those actions are present. So it is very good UI.

Duh, indeed. I should have checked in KDE 4 before writing, it's fine (except for your wish) in kate, indeed.

However, in kwrite / katepart, the Cancel button is still present, and should be removed, there. Well, I guess I should not have highjacked this report...

Well, here's the (trivial) diff to add ESC support. Are we still allowed to commit stuff like this?

Index: app/katemwmodonhddialog.cpp
===================================================================
--- app/katemwmodonhddialog.cpp (revision 750559)
+++ app/katemwmodonhddialog.cpp (working copy)
@@ -73,6 +73,7 @@
   setObjectName( name );
   setModal( true );
   setDefaultButton( KDialog::User3 );
+  setEscapeButton ( KDialog::User1 );

   setButtonWhatsThis( User1, i18n(
                         "Removes the modified flag from the selected documents and closes the "

Thomas, I didn't check it in KDE4 :-) There is no such button in KDE 3.5.8 (in Kate).

Ok, let's make this simple wish report really confusing ;-)

In KDE 3.5.8, there is usually is no Cancel button, indeed. *Unless* you disable the "Warn about files modified by external processes"! With this option disabled, you see the modified-on-disk dialog of the katepart (which asks about single files at a time, not all files at once). Fortunately this interesting bug seems fixed in KDE 4 (where - as expected - no dialog is shown at all in this case).

Anyway, the katepart dialog still has the Cancel button in both KDE 3.5.8 and KDE 4.

Thomas, where can I see this katepart?

I tried Kdevelop and it uses quite different notification dialog (bad imho), but anyway -- without cancel (on modification).

To see the katepart modified-on-disk dialog, either uncheck the "Warn about file modified..." option in kate (KDE 3.5.8), or use kwrite.

Thank you, it is terrible nasty awful thing :-) Brrr...

The report about it is here:
https://bugs.kde.org/show_bug.cgi?id=77990

And just in case, report about reinvented warning dialog in KDevelop:
https://bugs.kde.org/show_bug.cgi?id=154976

I hope only regular normal warning dialog remain, and the cancel button will go away with those dup.dialogs.

Actually the ignore vs. cancel separation is useful and the 2nd warning dialog when doing the actual saving is useful as well.

KWrite in KDE4 does the right thing, except that it doesn't have a reload-from-disk button. 

Ignore influences the showing of the warning when doing a save on the file, while cancel doesn't do that, which is quite useful.

I completely agree though that all those dialogs need to be somewhat unified across apps and thus should move to kdelibs. Both the one with "save-as,ignore,cancel" (which should get back the reload option as well as the one that pops up when hitting save and the file wasn't reloaded or ignore clicked on the first one.

Seems I confused something, or there's a slightly different dialog sometimes. Anyway I just retested kwrite/kde4 and it does have reload and overwrite and no save-as... The rest of my comment still stands though.

Andreas, you test the ugly notification dialog (in UI design terms). Please test Kate dialog -- it is really well designed.

Btw. cancel is meaningless in this dialog, because you can cancel action, not cancel information. It is like saying "today is saturday" --> "cancel".

I did test kate/kde4 as well and that one only asks me when I finally try to save the file, it doesn't notify me when the external change actually happens. Oh, wait apparently I had the option disabled, if thats the default it should change IMHO.

Anyway, that dialog misses a cancel button. That button is useful if I'm not sure I want to save what I started to write, but I also don't want to reload because I loose my already written data. Thats the use-case for cancel, because it will remind me when I actually do the save that there are changes from an external process which I might want to look at. While using Ignore disables that.

On Saturday 05 January 2008, Maciej Pilichowski wrote:
> Btw. cancel is meaningless in this dialog, because you can cancel action,
> not cancel information. It is like saying "today is saturday" --> "cancel".


If you cancel the dialog, nothing will happen, and the dialog will pop up 
again next time kate is focused, or a file that is modified on disk is 
selected within kate. That is, you postpone dealing with the situation. It's 
like "oh no, it's monday" -> close your eyes and try to go back to sleep, 
refuxing to realize that your mom will call again in a moment ;)

Anders, thanks for the explanation (good one :-)) ), but then it would be better to rename it to fit in 
reload / overwrite / ignore scheme.

My suggestion would be "remind me later", "not now", "close the dialog" (assuming the moment you try to do something -- edit/save -- you will have to make the decision). 

Yeah, "Remind Me Later" sounds good. That also fits quite nicely with the "reminder" warning when trying to save :)

Should I add another wish-report for this but honestly I am not sure where -- since there is no unified warning dialog. Maybe rather as additional wish for the other report?

In KDE 4.10, there are only 3 options Reload, Overwrite, Ignore Changes.

Maybe only Reload or overwrite would be best, then we don't have this intermediate state...?!

(In reply to comment #17)
> Maybe only Reload or overwrite would be best, then we don't have this
> intermediate state...?!

Arguably, "Ignore" causes a somewhat confusing state (that might be alleviated using some form of persistent notification, though). However, there are situations when I use it.

1. More frequent, but less important case: I had a file opened to check (not edit) it, then I moved, deleted, touched it outside of kate(part), and my view is simply obsolete. I do not want to revert back to the obsolete state (overwrite), nor do I want to reload a (potentially large) file. I want to close it.

2. Rare, but more important case: I have actually made some conflicting edits to the file, one way or another. I don't want to discard my changes in the katepart, but overwriting would be inappropriate, too. What I really want to do is probably copy some sections that I want to keep, then close the file. In this case, the choice between "Reload" and "Overwrite" would be mildly infuriating.

Dear user,

this wish list item is now closed, as it wasn't touched in the last two years and no contributor stepped up to implement it.

The Kate/KTextEditor team is very small and we can just try to keep up with fixing bugs. Therefore wishs that show no activity for two years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users.

If you want your feature to be implemented, please step up to provide some patch for it. If you think it is really needed, you can reopen your request, but keep in mind, if no new good arguments are made and no people get attracted to help out to implement it, it will expire in two years again.

We have a nice website kate-editor.org that provides all the information needed to contribute, please make use of it. For highlighting improvements our user manual shows how to write syntax definition files.

Greetings
Christoph