XnView Software

Hi,

Problem (on Windows XP):
1. Copy image from a CD to HD.
2. Make adjustments to IPTC (on the file on you HD).
3. Nothing happens (because the file is locked), you only see that no changes were made to the image.

Solution: Open the file properties and unlock the file.
Suggestion: Let XnView give some indication that the file is locked, and also suggest that you unlock the file. It is confusing that you don't get any response to why nothing happened to the image.

Troken

Hello !

• Probably, the copy keeps the Read Only attribute [r]… XnView might remove that attribute for a copy from a CD,
or any other non-writable medium like some good file managers do
- You can always remove the read only attribute, but I agree that the programme
should be “intelligent” enough to do this directly !

KR
Claude
Clo

Yes, a read-only indication would be good.

Btw, the same applies for the .ini file: There's no indication if the .ini file is read-only. Please note that sometimes the read-only of xnview.ini is set on purpose, so there should be a setting that suppresses the reminding.

Clo wrote:... XnView might remove that attribute for a copy from a CD,
or any other non-writable medium like some good file managers do ...

Good evening Clo,

Im actually not suggesting that XnView shall fix the problem, merly indicating that the file is read-only. This would be standard behaviour.

Your idea is taking the solution further: XnView could ask the user if it should remove the read-only attribute. Sounds interesting.

Helmut wrote:... Btw, the same applies for the .ini file: There's no indication if the .ini file is read-only. ...

Evening Helmut,

Hm... yes, there might even be other circumstances where you'd like to know that your changes were not made because of the read-only attribute. XnView should always notify the user that this is the case.

I don't think that XnView should set the read-only attribute back to R/W,
I sometimes use the Read-Only attribute to avoid accidental manipulations to an image,when I want XnView just to be a viewer.

XnView should however warn the user that the file is Read-only, preferably immediately if the file has been manipulated by XnView.

I think it is easy enough for all users to set the RO-flag to R/W by use of the explorer.

Just my opinion.,

René

rra

Hello !

… I think it is easy enough for all users to set the RO-flag to R/W by use of the explorer.

• Explorer ? What is it ?
- Troken is talking prior of images copied from a CD which inherit the Read Only attribute, that IMHO is rather stupid !
- Like I said above, i.e. Total Commander removes that attribute in the case.
- In other cases, for instance for an INI file set as Read Only (perhaps by admins in a company) that's another story…
- But about the original topic, I guess that there is no need to bore the user with one more blah blah message
breaking the workflow (and here, my nerves ! )

KR
Claude
Clo

Clo wrote:... But about the original topic, I guess that there is no need to bore the user with one more blah blah message
breaking the workflow (and here, my nerves ! )...

This is (IMHO) no a blah blah message. It is VERY important that your software notifies you that your command for some reason was not attended. I grant you: I dont need messages saying that it was succesfully treated, however if something malfunctions or can not be processed, then you'd really want to know. Preferebly informing what kind of error it was.

Just leaving the user thinking all is properly processed is not a good thing.

Troken is talking prior of images copied from a CD which inherit the Read Only attribute, that IMHO is rather stupid !

Sure, but if XnView would just reset the read-only flag without asking,
it would do so also if I intentionally set the Read-only flag on images originating from my harddisk.
that is not what I want XnView to do .
Main thing is that XnView warns about this situation, and let the user decide what XnView should do with it.

Rene

rra

Again…

• Tu sum up that issue and attempting to find an efficient solution,
I would propose an INI entry to make everybody happy, for instance :

[Start]
CopyReadOnly=Flag
0 :  Doesn't copy the read-only attribute from a non-writable medium only (CD etc.) without any warning.
1 :  Warns the user that the current processed file has the read-only attribute in any case,
but doesnt change anything.
2 :  Doesn't copy the read-only attribute from a non-writable medium and warns the user that it did.
4 : Warns the user that the current INI file has the read-only attribute,
hence his¦her setting changes will not be applied.

• Of course, a sum of compatible options should be allowed… “1” could be the default.
- What do you think ?

KR
Claude
Clo

I agree to this,
my (default) option would be "4" ,
but using the INI file everybody can tune the behaviour to its own needs !!

René