read only

[killerbot]

I was wondering with the latest changes wrt scintilla, the engine beneath our 'editor' tabs, which are files being opened.
Is the following quick to implement or modify.

When you open a read only file, you can not edit in CB, several editors allow editing and upon saving then tell it is read only, allowing you to force it to make readable, other sometimes ask you to force it writable at the moment of the first modification.

I think it would have added value to have this possibility in CB, so we don't need to leave CB to manually adjust the r/w flag.

Even when there are version control systems that make their files read only so you have to isse an explicit check out command, this still will have added value, I think.

Any comments, suggestions ?

[daniloz]

Hi killerbot,

Any news on this feature request ?

I am asking because I was thinking about implementing it, but first would like to be aware of the current status (anyone working on it?, etc...)

[oBFusCATed]

If I remember correctly Morten has done something related to ReadOnly files, I don't remember exactly what.
There was an old topic, where someone (Morten I think) had arguments against such feature.

[daniloz]

@oBFusCATed:

I am talking to Morten about it already, thank you...

[Jenna]

Just for the record, the file properties have a checkbox to set or unset the readonly status.

[daniloz]

@jens:

I am aware of that one and like it very much. However, the point is, if a file is already open and is read-only, then even after you go there and uncheck the Read-only attribute, you cannot edit the file. You have the close it and open again...

So, my first though was that the file status should be refresh after a change in the read-only checkbox... and all diverged to a more general discussion...

Thank you for taking me back to my initial point. Maybe this should be the first step in the implementation, a callback to whatever-is-needed-to-refresh-the-editor-read-only-attribute, so after the file properties dialog is closed, you can edit the file...

[killerbot]

wrt read only, there another issue to. I think when you go to the properties of a file, and exclude if from compile/link, then the checkbox of readonly gets active, and one has to ,manually remove the readonly attribute.

Dunno, about the reloading, but if that does not happen automatically, I think it should .Closing and opening a file, that's so windows like ;-)

[daniloz]

wrt read only, there another issue to. I think when you go to the properties of a file, and exclude if from compile/link, then the checkbox of readonly gets active, and one has to ,manually remove the readonly attribute.

When I look into the auto-reloading for read-only, I'll have a look at it as well...

Dunno, about the reloading, but if that does not happen automatically, I think it should .Closing and opening a file, that's so windows like ;-)

I am not 100% sure (and I don't have C::B available right now), but I think if you change the read-only attribute externally  (using TotalComander ;-), for example), then you can just switch to C::B ans start typing. BUT, if you use the file properties dialog inside C::B to untick the read-only, then you have to open and close the file in oder that the change is taken...

But anyway, I agree, that's so windows like :-p (btw, anyone - maybe jens - can report what's the behavior on *nix systems?)

@all:
I am still making my way through the source code, scintilla, wxwidgets and so on... so any hints about how the read-only attribute is treated (which class, updates etc..) would be MUCH appreciated... :-)

[MortenMacFly]

I am talking to Morten about it already, thank you...

an I am aware that I still have the task to create the patch. Hence time is limited atm... but it's not forgotten. Sorry. 

[daniloz]

an I am aware that I still have the task to create the patch. Hence time is limited atm... but it's not forgotten. Sorry. 

No problemo... My time is still limited, so I can still say that I'm not working on this issue because I don't have the patch from you... :-)

[MortenMacFly]

an I am aware that I still have the task to create the patch.

Here it comes (finally).

Not 100% working, but at least better than the current state.

Notice the following things in general (which makes things complicated btw):

• You need to differ between a file and an editor. While a file might be writable, an editor can be set to read-only. In that case, the editor state supersedes.
• Checking the file system for a file being read-only should only be done when really needed. This is time consuming. Thus we may fail some cases if e.g. a user sets a file read-only in the background (not using C::B). This should be handled if e.g. the file is opened (or used in any other way) and thus it's state is checked anyways.
• I am not sure how we handle if e.g. a file is read-only and under version control. I could imagine blending two icons here...?!
• Keep in mind that files can be changed in its state in many ways. Using the file explorer, the file properties or any plugin via SDK (e.g. setting an editor state to read-only). So there should be a common API (e.g. SDK event?!).
• Updating the project tree's icons is time consuming (especially for large projects / workspaces). I'd prefer only to update the visual part if possible...

Patch is attached... not implementing the above. ;-)

[daniloz]

Here it comes (finally).

Ok, thank you!!! I've downloaded it and will have a look... I let you know...

[daniloz]

@jens:

I am aware of that one and like it very much. However, the point is, if a file is already open and is read-only, then even after you go there and uncheck the Read-only attribute, you cannot edit the file. You have the close it and open again...

So, my first though was that the file status should be refresh after a change in the read-only checkbox... and all diverged to a more general discussion...

Thank you for taking me back to my initial point. Maybe this should be the first step in the implementation, a callback to whatever-is-needed-to-refresh-the-editor-read-only-attribute, so after the file properties dialog is closed, you can edit the file...

I finally manage to get some time to look into this issue and, actually, there's a very simple way to do the refreshing, by using the CheckForExternallyModifiedFiles() from the EditorManager... The patch is attached, please feel free to test it... :-)

Expected behavior: when you right-click on a tab or file, go to "Properties..." and then change the "File is Read-Only" flag, the editor is refreshed automatically to reflect the new flag.

Old (actual trunk) behavior: The editor is only refreshed and reflect the new Read-Only state after you trigger a CheckForExternallyModifiedFiles(), either by closing it and opening again or by clicking outside C::B and coming back, so it regains the focus (on Windows)