XnView Software

To be honest, it's already hard for me to say whether this is a bug or a changed program logic, but when I asked Pierre about it via e-mail in early October, he wrote that it was a bug. Unfortunately, it was already in 0.99.1 and passed in 0.99.4. I will repeat an excerpt from that letter, because the behavior of the resize dialog has not changed - for some pictures, when opening the resize dialog (shift+s) in 0.99.1 (now in 0.99.4 too), a size different from the original one began to be indicated. There was literally no such behavior in 0.99.0.

It is reproduced not in every picture, but very stable. Now I have 0.99.4 on hand and the just downloaded portable version 0.98.4. It seems to me that, observing the resizing dialog in them, I can now formulate the problem more precisely - in 0.99.4 in resize dialog for some reason "last used" preset began to be selected on every opening, while up to 0.99.0 it was offered "by default" every time you open this dialog. That is, now, due to the "last used" preset, each next open picture in the resize dialog by default gets the size from a completely different picture, opened unknown when. This is extremely inconvenient =(

I have also seen unexpected size displays that I didn't understand, and suspect that any bug was introduced following implementation of a recent request to make some 'last used' settings persistent, which would be a useful enhancement...

If so, it shouldn't be hard to find?

Now you have to manually switch from "last used" to "default" each time. For me personally, this is inconvenient in relation to the old behavior of the program. Maybe there is some kind of setting regarding the resize dialog presets? I have not found one. In the ini-file, the ResizeDlg parameter is spontaneously rewritten by something from the outside, I don’t know what.
I think it would be appropriate to set the "preferred preset" for the resize dialog (in .ini or explicitly in the UI of Xnview itself).

I saw a seeming issue recently but haven't been into it in detail: my long-standing wish was for the Mode (Pixels | Percent| ...) setting to be persistent, as when processing a series of images having to reset that setting every time was tedious.

Debatable whether some other setting would be better persistent, quite possibly some would...

As it is regression to the previous code would be better, but it should be possible to implement the original request, or maybe a refined version, successfully.

RickyPatter4728 wrote: Fri Dec 03, 2021 1:56 pm Now you have to manually switch from "last used" to "default" each time. For me personally, this is inconvenient in relation to the old behavior of the program. Maybe there is some kind of setting regarding the resize dialog presets? I have not found one. In the ini-file, the ResizeDlg parameter is spontaneously rewritten by something from the outside, I don’t know what.
I think it would be appropriate to set the "preferred preset" for the resize dialog (in .ini or explicitly in the UI of Xnview itself).

Right, there was a change, now 'last used' is always used. For you, image size 'default' should be used like before?

xnview wrote: Sun Dec 05, 2021 10:41 am Right, there was a change, now 'last used' is always used. For you, image size 'default' should be used like before?

Absolutely right. I think at least it would be nice to have the user select a default preset for resize dialog, if possible. Perhaps that would be as fair as possible.

you have the new option 'Load Default values'

xnview wrote: Sun Dec 05, 2021 1:32 pm you have the new option 'Load Default values'

How is it supposed to work? Every time I open the resize dialog at 0.99.4, this flag is inactive, and when I set it, it does nothing! The old logic with the "default" preset set at each opening was clear and simple, now, from my point of view, the work of the dialogue is complicated and broken.

Thanks to your detailed description I can reproduce the problem.

This option is not restored correctly...

This problem is supposed to be fixed in XnView MP 0.99.5. Please check and confirm the bug fix here.

Seems it works now, thanks!