[Bad user experience and a bug] File handling and "R-only" vs. read-only

[Olf0]

Maybe I have a significant misconception here, but it seems that the handling of files and their "R-only" / read-only attribute is not modeled well in Editor.

On s conceptual level, a "document" (i.e. a text in Editor.) can be ...

a. not being backed by a file.
Situation a. arises, when Editor. is started directly (i.e. without a backing file), or when the backing file was moved (including renamed) or deleted after opening it with Editor.

b. backed by a read-only file.
Situation b. arises, when a read-only file was opened with Editor., or ...
well, that depends on the exact definition of what the "R-only" button in Editor. should do (see below).

c. backed by a writable file.
This is the regular, easy situation: Nothing special to consider / model.

IMO, each of these three situations should be handled by the same mechanisms / behaviour of Editor., when hitting the "Save" button.

The simplest approach is to handle situations a. and b. the same:
Emit (i.e. notify) "Cannot write to file!" (currently "Can't save document!").
Then Editor. may either automatically call "Save as" or do nothing.

For situation c., the document is written to its backing file.

The "R-only" seems to be rather only a "Disable keyboard" / "Prevent typing" button (which O.K., but just a first step, IMO), currently (I have not taken a look at the code):

• One can hit "Save" while "R-only" is active and the document is saved to its backing file! So it is definitely not read-only! This is quite irritating.
  So when "R-only" is active, please either "gray out" (and disable) the "Save" button or proceed as described for situations a. and b. (above, "The simplest approach ..."), when "Save" is hit.

• When opening a read-only file, the status of the "R-only" button is "off". Also an unexpected user experience, IMO.
  So please check (but do not test by writing to it), if a file is writable when opening it, and set the "R-only" status accordingly. "R-only" should be "grayed out" or not toggleable (but active!), as long as the backing file is not writable.

• Starting Editor. directly (i.e. there is no backing file) can be handled just the same (as with a read-only backing file, in the point before).

• If Editor. can be informed (by Qt or something else), that its current file handle is not valid anymore (because the backing or backup file was moved / renamed / deleted), use this information to display a notification and go to the same state as mentioned in the two above bullet points.

• When a read-only file is opened in Editor. and one hits the "Save" button, it simulates saving to the read-only file (but sure cannot really write) and no error message is provided! Actually the document is written to the backup file <filename>~. I consider this as a bug. This would be resolved by implementing aforementioned suggestions.

Further remarks:

1. [Usability suggestion] When a file is freshly opened, Editor.'s "Save" button is not "grayed out", although there are no unsaved changes to the document (obviously, as just opened)! This is inconsistent with Editor.'s subsequent behaviour (when saving after having typed something) and hence confusing. So please implement the suggestion in the third bullet points above or at least "gray out" and disable Editor.'s "Save" button for freshly opened files.

2. [Usability suggestion] After performing a text selection, but without altering the document, the formerly "grayed out" "Save" button becomes active! This is also inconsistent behaviour (as the document was not changed). Please keep the "Save" button grayed out after text selections without changes to the document.

3. [Feature suggestion] When the backup file (with the "~") cannot be created or written to, notify about that (e.g. "Cannot create backup file." and separately "Cannot write backup file."). Currently this is indistinguishable for the user from a successfully written backup file (as there are no such notifications).

4. [Usability suggestion] Change the notification "Document saved!" to "Document saved.", as there is nothing special or something to warn about in this notification.
   The same applies to all other notifications representing affirmative (i.e. positive) feedback ("!" --> ".").

5. [Usability suggestion] Insert " <filepath>" in all notifications (after the word "file" in above suggestions for the notification messages) concerning file operations, when Editor. has a file handle for a backing or backup file.

BTW (just curious) is Editor. part or even topic of an semester / diploma / master work or thesis you do?

[GoAlexander]

You wrote so big text :) I don`t have enough time today so I will comment only some thing but I will reread all your issues in the future.

R-only was planned only "to disable keyboard" as you sayed. I had some cases when I wanted to read text but I wanted to protect the text from accidental clicks.

[Usability suggestion] After performing a text selection, but without altering the document, the formerly "grayed out" "Save" button becomes active! This is also inconsistent behaviour (as the document was not changed). Please keep the "Save" button grayed out after text selections without changes to the document.

I know this is a bug. At the moment it is not so easy to fix it but I will do that in the future.

BTW (just curious) is Editor. part or even topic of an semester / diploma / master work or thesis you do?

Editor is my hobby :) but in this semester we have subject "Project work" where we had to implement real projects (the teacher suggested list of topics) but I did not like suggested topics so I asked teacher about Editor (it was already in development). The teacher agreed. So I have a team (which is not so motivated but I got some code (features) from them) (for example I wait in this month from the team: sending document to the Dropbox and support of RegExpressions) and will get the mark for this project :)
Comment: The "project" is not all Editor but only part of Editor only some features.

My course work is much more harder :)))

[Olf0]

R-only was planned only "to disable keyboard" as you said.

Well,

... which O.K., but just a first step, IMO ...

Actually, this was a cool idea (to disable the keyboard), which I do like.
But in its current state the "R-only" behaviour is not what "read-only" is about, which is confusing.
Also the handling of real read-only files is non-existent (as described above), and best would be integrated into the "R-only" feature, IMO.
Thus I tried to outline the steps to extend the "R-only" feature to work as one may expect.

All in all, when testing Editor.'s behaviour in the cases a., b. and c. above, I had the impression that an abstract, behavioral model of (i.e. an overarching concept to handle) these cases is lacking.
Indeed, describing these issues, trying to model proper behaviour and drafting specific suggestions made the original message rather lengthy. But all these aspects belong together, as this is a single topic of mutually dependent behaviour and functions, which ought to be looked at as a whole! At least I should have abstained from including the observations of just loosely related issues under "Further remarks".

And thanks a lot for explaining the background of Editor.'s development.

Do you want me to create separate Github-issues for issues 1. to 5. (in the section "Further remarks" of my original message)?