jpegview
jpegview copied to clipboard
JPEGView.ini.tpl file not up-to-date with JPEGView.ini
The file JPEGView.ini.tpl seems to be not exactly up-to-date : in particular, it still defines the "ColorCorrection" option with quotes (while since #12 it seems it shouln't...)
Moreover, around definition of Users command, it seems to be a little outdated versus JPEGView.ini (even if i'm not sure in this second case...)
So, the JPEGView.ini and the .tpl files... I've been a bit busy recently but I'm trying to redesign the layout for that... the way the JPEGView.ini and the template and the user config interact is really clunky right now and it's something I want to change...
Oh, so I didn't address the actual issue. So right now, the .tpl
file is what JPEGView uses to create the "user" ini. Plus, there's the internationalized versions.
But it's not the active use INI... the JPEGView.ini itself has an option which states which INI it's going to use. There's also a command line option and it cascades from
user -> "inside JPEGView directory" -> code defaults
But the tpl files just don't get updated as much, and I feel like it's really duplicative... so, I was going to get rid of it entirely. But the way it's structured right now, really can't without making some JPEGView.ini un-editable. ... still designing...
The issue is the fact that the tpl file is used to create the initial user ini file. As a result, even if the tpl is not "active", the user ini file (that is "active") is then wrong for the ColorCorrection parameter. Obviously, it can be easily corrected afterwards... but it would be better it is corretly initialized....
Right. So I created a branch but was ready to overhaul the whole bit... because I think the whole thing is really clunky. Oh, in addition, the keymap.txt
needs to work the exact same way (that's why it's taking some time to figure out), aka like issue https://github.com/sylikc/jpegview/issues/40
I think I'm almost ready to try to tackle this problem... still deciding how to necessarily cascade the settings with the least confusion... I don't think the original author really thought about the non-portable use case