Keys file codification causes some keys to not be read
Posted: Sat Aug 13, 2016 8:33 pm
I think this also applies to non-beta XnViewMP, but since I discovered it with 0.82 Beta 4, I think it's better in this forum.
In short: XnViewMP doesn't save the key configuration in UTF-8, but it's the codification which seems to not give problems with strange characters/keys.
When opening in full screen mode, the default change mode is Viewer<>Full Screen; and there's no Browser<>Full Screen only setting, only Browser<>Viewer. I don't like using the viewer and I never liked having to pass through it to access the browser, nor using a 2-key combo for it, since all the obvious 1-key are already taken. I've already tried this before, but it didn't work, and it's assigning 'browser' to the key directly below ESC. In my keyboard it's the key for º and ª and backslash. However it doesn't work: at next load, XnViewMP just shows a bad sign in its place.
Since the last time I tried it, I've done some development involving loading tons of data from text files, so I thought of the codification and... That was it. The pertaining .keys file was in ANSI. XnView doesn't load it right. I just transformed it into UTF-8 and XnView was able to load and interpret correctly the key assigned. As long as I don't overwrite it again, because XnViewMP doesn't save it in UTF-8. Apparently UTF-8 doesn't give problems for reading, but the program doesn't save in that codification. Which is strange, since Windows and well, all modern OS have perfect support for UTF, along with any decent programming language which should have a good UTF library.
Regards.
In short: XnViewMP doesn't save the key configuration in UTF-8, but it's the codification which seems to not give problems with strange characters/keys.
When opening in full screen mode, the default change mode is Viewer<>Full Screen; and there's no Browser<>Full Screen only setting, only Browser<>Viewer. I don't like using the viewer and I never liked having to pass through it to access the browser, nor using a 2-key combo for it, since all the obvious 1-key are already taken. I've already tried this before, but it didn't work, and it's assigning 'browser' to the key directly below ESC. In my keyboard it's the key for º and ª and backslash. However it doesn't work: at next load, XnViewMP just shows a bad sign in its place.
Since the last time I tried it, I've done some development involving loading tons of data from text files, so I thought of the codification and... That was it. The pertaining .keys file was in ANSI. XnView doesn't load it right. I just transformed it into UTF-8 and XnView was able to load and interpret correctly the key assigned. As long as I don't overwrite it again, because XnViewMP doesn't save it in UTF-8. Apparently UTF-8 doesn't give problems for reading, but the program doesn't save in that codification. Which is strange, since Windows and well, all modern OS have perfect support for UTF, along with any decent programming language which should have a good UTF library.
Regards.