REQ: INI file in XnView folder - for USB stick

[helmut]

BTW How can I save settings to Document & Settings... ? There is no such option in xnview, I still think it's confusing.

Currently, XnView checks which folder is writable for saving the option (in the same order as XnView tries to read the options).

[Dreamer]

BTW How can I save settings to Document & Settings... ? There is no such option in xnview, I still think it's confusing.

Currently, XnView checks which folder is writable for saving the option (in the same order as XnView tries to read the options).

I misunderstood - how can I get "support settings per user" in Document & Settings... folder.

Is possible to use 2 xnview.ini files for 2 windows users? And how?

Thanks.

[helmut]

Is possible to use 2 xnview.ini files for 2 windows users? And how?

Currently this is not supported. But you can achieve this with a trick, I think:

As written above, the sort order of XnView for .ini files is
1. Windows
2. Program
3. Document & Settings

If you want an .ini file per user, you copy the xnview.ini to ".\Documents & Settings\<User A>\AppData\XnView". (In that directory should be a bookmark.ini, already).
You do the same for user B. Last not least you rename or delete your xnview.ini file in Windows or Program directory. Due to the search order XnView will find the user specific ini files and you have individual settings, then.

Sure enough, this is just a workaround and not a general solution. With the search (and save) order the other way round, as suggested above, this would not work either.

Think the settings read and the settings saved should be the same. If no setting was found, the order for saving new settings should be
1.) Document & Settings
2.) Program dir
3.) Windows dir

This way you would have always user-specific settings. The question left open is how you would get settings which are valid for all users. Think somewhere a setting "Use same settings for all users" which affects search/save location is needed.

[Dreamer]

Helmut,

thanks, I agree with you.

Maybe this would be enough:

1. Document & Settings... (auto per user)
2. Program dir (auto all users)
3. Registry (auto per user)

How many users need Windows dir? It's not easy to find .ini file, not easy to backup and easy to move or delete another important file .

[Danny]

You have to keep in mind that limited Windows accounts don't have write access to the Windows folder and the registry IIRC.

[OL]

Also, do Windows 98 and ME have Document & Settings folders?
%appdata%\XnView would be interesting, or My Documents.

[Dreamer]

You have to keep in mind that limited Windows accounts don't have write access to the Windows folder and the registry IIRC.

Therefore Registry is 3rd and I want also remove / don't use Windows folder.

I think my idea above is the best, I hope it is also easy to implement .

Also, do Windows 98 and ME have Document & Settings folders?

No, this could be the problem.

%appdata%\XnView would be interesting, or My Documents.

1. Document & Settings... (auto per user) - "Document & Settings..." is not the full path, full path should be this:

".\Documents & Settings\<User A>\AppData\XnView". (In that directory should be a bookmark.ini, already).

[xnview]

Instead, I suggest another search order. Currently, XnView searches from general (Windows) to detailed (Document & Settings). The search should acutally be the other way round, from specific to general:

1.) Program directory (where xnview.exe that is just started resides)
2.) Document & Settings
3.) Windows directory

This would allow for having specific settings on an USB stick and also support settings per user.

I agree.

Ok, i change, but don't change the option dialog

BTW How can I save settings to Document & Settings... ? There is no such option in xnview, I still think it's confusing.

When app folder has no write/create right, it's used

[Dreamer]

And what about this? In 1.81 maybe?

1. Document & Settings... (auto per user)
2. Program dir (auto all users)
3. Registry (auto per user)

[helmut]

Behaviour of .ini file has been changed in RCs (<=4). Other issues are postponed.