XnView Software

Early testing but it seems to work fine now. Thank you very much! :) :bugfixed: Still couldn't figure out which parameter sets the chosen setting during the first xnview startup (when xnview.ini is missing). Not a big deal, just wanted to fix my .ini manually. ;) https://i.imgur.com/f9qVBS9.png

Early testings, but it seems to be fixed alright! Fonts look good, no more fontconfig errors.
Thank you very much! <3

Had you used the search function, you would have seen topics on the subject already opened.

Anyway, this should be fixed in the next version 0.88 soon.

Thank you for resolving this. Ref. https://www.xnview.com/mantisbt/view.php?id=1317 I'll chime back next version to confirm. Side note: Is there a particular line in the xnview.ini that specify what option xnview is using regarding the config paths? I couldn't find one that does a difference. [DB] b...

Thank you Pierre, I can confirm this bug is now fixed in 0.87. 8) Side note: While testing, I managed to crash it again by doing something fast (I think after moving the toolbar around a bit) and then removing some files. But that's a story for another bug report later when I can reproduce consisten...

Sorry for the very late reply, I didn't receive any notification. I tested in 0.87, and the problem remains the same. Although, specifying the full path to the default.keys and default.bar in the xnview.ini file as mentioned above is still a valid workaround. From xnview.ini: shortcut=default.keys t...

Same problem here (Arch Linux 64 bits), downgrading libfontconfig.so to 1.9.4 seems to fix this problem, making a symbolic link to the library should be enough ln -sf /usr/lib/libfontconfig.1.9.4 /opt/xnviewmp/lib/libfontconfig.so.1 My current xnview.sh looks like this: export LD_LIBRARY_PATH="$dirn...

Found which setting causes the crash. In ~/.config/xnviewmp/xnview.ini Under section [Start], these values cause the crash eventually as described above: StartInFull=0 or StartInFull=1 This value doesn't crash at all! StartInFull=2 This setting corresponds to the General-> Mode when starting with a ...

I keep getting this crash every day, sorry to keep reporting on it. I'd like to find out what's causing this. I have noticed something else that could be related: Whenever I delete a file via XnViewMP, its deletion is not reflected in the Browser view mode. It's still listed as if it wasn't moved to...

What happens when you delete a file? Is it not updated in the tree view either?

Edit: there is an option in settings -> interface -> Synchronize browser when view is closed. This is probably what you are missing here.

Yes pretty much. Althouth I've tested some more today and a file being opened in viewer mode doesn't have to be in the delete queue after all: Let's say I have files names file01 to file20. I'm in edit mode for file20. In browser mode, I delete file01 up to file19. Xnview will crash. even though fil...

Good news, I've found a more reliable way to reproduce the crash: You have to keep at least one of the soon-to-be-moved (or deleted) files opened in view mode while moving (or deleting) files in browser mode. Edit: not true. Note: in view mode, if I go back to a file that is about to be deleted (as ...

Ok, I fixed it by replacing the following key values in the xnviewmp.ini file. These were the ones I had previously: shortcut=default.keys toolbar=default.bar I replaced them with these and it works now: shortcut=/home/user/.config/xnviewmp/default.keys toolbar=/home/user/.config/xnviewmp/default.bar

OK, I guess it's just a library version mismatch somewhere. My system libs must be more up to date than the ones shipped with xnview. Back to square one then. If I use the bundled libs, I have the font glitch . EDIT: ok nevermind, it seems it doesn't crash anymore since 0.86 rel1. EDIT2: nevermind ...

No, I'm using the tgz file from there http://download.xnview.com/XnViewMP-linux-x64.tgz I manually extract to /opt/xnviewmp It was reading the file correctly in 0.84, since 0.85, it's not looking in .config anymore. The .ini files are properly read from the .config directory though! It's very odd th...