improvements to file change notification/indicator

[avih]

The file change notification is useful, but I don't think it should popup unless NP3 has focus.

It can be seriously annoying, and can also actually cause data loss, because if the user works in some other context, and suddenly the notification dialog pops up and steals the focus, then key presses start going to NP3, and can accidentally dismiss (ESC) the dialog and/or start typing into the current document in NP3, and then it's not reloaded, and other similar issues from unexpected change in focused app.

I'm not aware of any other windows application which steals the focus when it wants to show some notification. It's simply bad practice. Terrible even.

I would suggest, as a first step, to never show the change notification when NP3 is not focused, and do show it once it gains focus.

As a second suggestion, once NP3 gains focus, only show the dialog if it's still modified on disk compared to the view. I.e. it's possible that the file got modified and restored before NP3 got the focus again (e.g. can happen frequently when switching branches forth and back in git), so it would be nice to not interrupt the user (this might already be the case. I didn't test it).

I'm not familiar with the implementation details, but maybe both the above can be achieved by simply suppressing the file-changed checks when NP3 is not focused?

Then, maybe later, consider replacing the popup dialog with something less intrussive, like maybe a non-modal yellow overlay message at the top of the content area, or some such (which can still have UI elements like a reload button etc), so that it becomes clearly visible, but still not interrupting in case the user is typing at the document etc.

FWIW, I'm using 6.24.309.1 RC3.

Regardless, do keep up the good work!

[avih]

I tried maybe disabling change notification and instead set

FileChangedIndicator=[MODIFIED-ON-DISK]

To make it easier to notice, but it seems to display only the first 3 chars or so and not the full text (the title bar is very long, most of it is empty anyway).

Is it possible to permanently enable the titlebar indicator (i.e. keep checking the file at the interval) without the popup dialog, for all files? I think the same state as if the user clicked "Cancel" at the popup, but without ever popping up the dialog.

I'm only seeing FileCheckInverval and FileChangedIndicator at the ini, and I'm not seeing anything specific to the popup, so maybe it's either check-and-popup-until-cancel, or never-check-or-popup?

Another thing I thought of to make it obvious but not intrussive that the file changed is to simply change the background color of the document (or the menu/status/tool bar background) instead of or in addition to the titlebar indicator.

That would be both 100% impossible to miss, and also 100% unintrussive, and without the effort of new UI elements etc, and no issue if it happens when unfocused.

It would also be nice to remove the titlebar indicator (and restore the bg color if that's implemented) if it returned to the same content on disk as it was before the notification/indicator was added. I tested, and if, in another app, I change the file and restore it, then the NP3 indicator does not go away, eventhough the user probably doesn't consider it modified on disk - because the file on disk is the same as it was when the file was loaded or last-saved.

FWIW, this is roughly what vim does:

• As long as it's not focused, there's no indicator.
• Once vim gains focus, then if the file on disk is same as as it was at the last-save-or-load, then it behaves as if nothing happened - no message, no indication (even if it was modified since last-save and then restored). and if it's modified then it shows a vim-modal UI element (which doesn't steal focus from anything) suggesting to ignore or load the file etc. I think it's reasonable.

[hpwamr]

It seems a duplicate issue of: #5320

As I'm waiting for new updates, I'll release a new RC3 version in a few days. 🤔

[avih]

It seems a duplicate issue of: #5320

For the main annoyance that it steals the focus, it does look like it (I did search other issues, but not PRs...).

But here are further suggestions on how to make the notification more useful, mainly:

• More visible indicator without notification, like yellow background for the content or tool/menu/status bar.
• Suggestion for less intrussive notification, like an embedded, non-modal UI element at the top of the content.
• A suggestion to not show the notification (or suppress the test) while NP3 is not focused.
• A request to automatically remove the indicator if the file on disk was restored to the state it had before the indicator showed up.

And an additional issue that the title inticator text seems to be limited to 3 chars or some such, but users might want to use more, to make it more visible, like FileChangedIndicator=[MODIFIED-ON-DISK].

A question on whether it's possible to enable the indicator without the notification by default, without having to click "Cancel" at the first notification - I see two config values FileCheckInverval and FileChangedIndicator, but I don't know which values to use to make that happen, if at all possible.

[avih]

It seems a duplicate issue of: #5320

I tried the appveyor build. It indeed doesn't steal the focus anymore, but it still shows the message box, which results in popping and blinking the windows status bar - and also show it if it's in autohide mode, so that's still more intrussive than I'd hope.

I also looked at the code a bit, and while I don't have VS to build it (no mingw, eh?), it looks like it should not be too hard to simply suppress the file change observer while NP3 doesn't have KB focus?

[hpwamr]

I see two config values FileCheckInverval and FileChangedIndicator, but I don't know which values to use to make that happen, if at all possible.

Well, please take a look at this closed issue: #5309 (comment) and also this opened issue: #5311

[avih]

Well, please take a look at this closed issue: #5309 (comment) and also this opened issue: #5311

Thanks. I missed that config dialog (or maybe didn't realize it opens a dialog - it looks like a checkbox at the menu...)

Do you want to keep the other subjects here, or open new issues for them - the 4 bullet points here #5325 (comment) and the only-3-chars-title-indicator ?

As far as I can tell none of them are addressed even with that PR which avoids the focus steal.

EDIT: well, the 3-chars limit seems fairly trivial to increase:

Notepad3/src/Notepad3.c

Lines 12662 to 12666 in cad0548

	if (IsFileChangedFlagSet()) {
	if (IsFileDeletedFlagSet()) {
	StringCchCatN(nid.szTip, COUNTOF(nid.szTip), Settings2.FileDeletedIndicator, 3);
	} else {
	StringCchCatN(nid.szTip, COUNTOF(nid.szTip), Settings2.FileChangedIndicator, 3);

[hpwamr]

Do you want to keep the other subjects here, or open new issues for them - the 4 bullet points here #5325 (comment) and the only-3-chars-title-indicator ?

Honestly, the main issue in "Notepad3 Development" is this comment: #5176 (comment)

[avih]

If I get that right, then the issue is current lack of active devs, yes?

In that case, I'll change the title to reflect the subjects, and I'm re-posting the subjects here if anyone wants to make some improvements. Thanks again for the replies and info.

Summary:

The original issue of the file-change notification stealing focus was addressed recently at #5320 .

Further suggestions:

• The titlebar file-changed indicator is hard-limited to 3 chars. It would be nice to increase it to 30 or some such to allow more visible indicator, e.g. using FileChangedIndicator=[MODIFIED-ON-DISK] (see source code at improvements to file change notification/indicator #5325 (comment)).
• Allow a more visible indicator without notification, like yellow background for the content or for the menu/status/tool bar etc.
• A suggestion to not show the notification (or suppress the test) while NP3 is not focused. The current code still shows a dialog, which can open an auto-hidden windows status bar, and blink the NP3 item - which is not required when the user works on other things.
• A request to automatically remove the indicator if the file on disk was restored to the state it had before the indicator showed up. This can happen, for instance, when changing a git branch forth and back, and the edited file is different between the branches, but restored to the same state once the original branch is checked-out.
• Suggestion for less intrussive notification, like an embedded, non-modal UI element at the top of the content.

[lhmouse]

Further suggestions:

• The titlebar file-changed indicator is hard-limited to 3 chars. It would be nice to increase it to 30 or some such to allow more visible indicator, e.g. using FileChangedIndicator=[MODIFIED-ON-DISK] (see source code at improvements to file change notification/indicator #5325 (comment)).

I kinda agree with this. The current indicators we have [@] and [X] is not quite intuitive and may surprise people when they see it for the first time.

• Allow a more visible indicator without notification, like yellow background for the content or for the menu/status/tool bar etc.

This is over-complicated and not more intuitive.

• A suggestion to not show the notification (or suppress the test) while NP3 is not focused. The current code still shows a dialog, which can open an auto-hidden windows status bar, and blink the NP3 item - which is not required when the user works on other things.

This makes sense, and Visual Studio does that.

However I still prefer the current behavior, as it immediately indicates a conflict rather than postpones it. If there are unsaved changes in the other editor then those must either be saved or be thrown away, which requires attention.

• A request to automatically remove the indicator if the file on disk was restored to the state it had before the indicator showed up. This can happen, for instance, when changing a git branch forth and back, and the edited file is different between the branches, but restored to the same state once the original branch is checked-out.

I think this is a feature or limitation depending on how you interpret it: The reload operation is part of a change and can be undone. In order to clear change history it might be necessary to clear undo history, which is probably not desired.

• Suggestion for less intrussive notification, like an embedded, non-modal UI element at the top of the content.

[hpwamr]

If I get that right, then the issue is current lack of active devs, yes?

Yes, the main issue of Notepad3 is the lack of C++ developers. 😬
See comment: #5176 (comment)

[avih]

• The titlebar file-changed indicator is hard-limited to 3 chars. It would be nice to increase it to 30 or some such to allow more visible indicator ...

I kinda agree with this. The current indicators we have [@] and [X] is not quite intuitive

Note that this doesn't request to change the default. Only to allow strings longer than 3 chars at the ini file.

Changing the default is of course also an option, but I wasn't advocating for that. FWIW, even if I would use a bigger string myself, I think the current default is OK.

• Allow a more visible indicator without notification, like yellow background for the content or for the menu/status/tool bar etc.

This is over-complicated ...

Not sure what "over complicated" is. Do you mean "would take too much effort/code for too little value"? If yes, then no comment about the effort/code, as I'm not familiar with the code.

and not more intuitive.

Correct, but the goal was not to be more intuitive. It's It was to become more visible and harder to miss accidentally.

The use case here is when the notification is disabled and only the indicator tells the user that the file was modified.

If you're editing a file, especially towards the bottom of the window, or you're comming back to NP3 after you were working in some other window, then you're much more likely to notice that the statusbar or toolbar or main text area background changed to yellow, than you would notice [@] added to the title bar (and obviously [@] can still appear at the titlebar).

If you look at all my suggestions, they are all around the same thing: acknowledge that it's important to know that the file was modified, but also that the current notification is really jarring, so one suggestion was for unintrussive, non-modal notification, but knowing that it can be non-trivial to implement, I was trying to make it easier to live with notifications disabled but indicator enabled - by allowing for a more visible indicator, like allowing longer text at the title bar, or yellow background someplace, etc (not by default. The current default of [@] at the titlebar and no background changes are fine IMHO).

• A request to automatically remove the indicator if the file on disk was restored to the state it had before the indicator showed up...

I think this is a feature or limitation depending on how you interpret it

I Agree. This can be subjective. Same for not showing the notifications until NP3 gains focus (however, do notice that all the other editors listed below don't do anything visible while the editor doesn't have focus).

For what it's worth, here's how Notepad++, Geany, and Visual Studio code behave with file-modified-on-disk (I don't recall changing the default regarding file-modified, but I might have long time ago).

Notepad++ pops a modal file-changed notification dialog when it becomes focused (asking "Reload?" [Yes] [No]). The dialog still shows even if the file was restored to its earlier state before the focus returned to NPP, and even if there are no unsaved changes at the NPP side. I.e. if you click "Yes", then nothing changes at the content, and I ask "did you really have to interrupt me with this dialog, when it doesn't do anything?".

That last thing is especially true anywhere - don't interrupt me with a dialog asking for some action if you (the app) know that this action would be no-op.

Knowing that the file was changed but restored could have some informational value to some users, though personally not for me (and I would probably know that anyway, because it was me causing these changes, like git switching branches).

Geany is almost identical to NPP (notification only when focused, effectively modal, even if the file was restored, and regardless of unsaved changes), and it has 3 buttons "Reload", "Cancel" (i.e. don't reload), and "Overwrite" (which I think saves the content inside Geany, overwriting the changes on disk).

Visual studio code: if there are no unsaved changes, then it reloads the file quietly whenever it changes on disk. No notification or message at all (that I could tell).

If there are unsaved changes then the file is not reloaded, and also no notification or indicator that I could tell. But when trying to save it, there are two cases:

• If the file was restored to the state before the unsaved changes were added, then it simply saves it and doesn't say anything.

• If the content on disk is different than before the unsaved changes were added, then it pops an embedded dialog at the bottom right, saying:

  Failed to save 'foo.c': The content of the file is newer. Please compare your version with the file contents or overwrite the content of the file with your changes.

  And has two buttons: "Compare" and "Overwrite".

Overall, I think the vscode approach is more complete and least interrupting (but more complex), escpecially with no unsaved changes or the file on disk is the same as before any unsaved changes were added. But with unsaved changes I think it can still be improved by offerring "Reload" as well, either whenever the file changes (and its content are different) or during save.

Not suggesting that NP3 should try to follow any of those specifically, but it's some food for thought.

[hpwamr]

I'll release a new RC3 version in a few days. 🤔

Hello @avih ,

Feel free to test the "BETA/RC PortableApps", version "Notepad3Portable_6.24.1125.1_rc3.paf" or newer, see the 1st list in issue #1129.

• Notepad3Portable_6.24.1125.1_rc3.paf.exe.7z -s

"Notepad3Portable BETA/RC PortableApps" version can be used with or without ".7z" extension.

Also, feel free to test the "BETA/RC Setup", version "Notepad3_6.24.1125.1_rc3_Setup" or newer, see the 2nd list in issue #1129.

Comments and suggestions are welcome... 😃