Replies: 3 comments 7 replies
-
I like idea 1 and 2I like idea 1 and 2... I'll have to think about how to make the changes for that. Thanks for the suggestions! I never really thought about 2 for some reason, but that's a pretty elegant solution... in code it might be "interesting" to put it lightly lol. Otherwise, in 1, I'd have to make sure I make the changes once and done, because it affects all repackaging of JPEGView (aka, PortableApps, Scoop, Chocolatey, etc etc etc) since it changes the filename and behavior of the JPEGView persistent user changes. Anyways, yeah I really like 2. For some reason I didn't think of it haha. So, I'll think about that and probably do testing on that. Where in the UI...The biggest annoyance I have right now is, I just can't tell which INI is loaded... like I don't know where to display it. I was going to put it into like the I'm just not sure where in the UI it most logically fits. |
Beta Was this translation helpful? Give feedback.
-
I'm not quite sure I understand what you mean. Aren't both ini's always loaded? I can't read code, but I always assumed that both ini's are loaded, all settings are read twice, and in case of conflict the setting from user-ini is applied. |
Beta Was this translation helpful? Give feedback.
-
|
So... it actually gets more fun beyond that. (I recall) A localized version is loaded if that exists... so in the case of RU, What I want to display is... if user-ini doesn't exist, all settings are from global. When There's also the feature of like loading a specifically named INI from the command line... in which case I would want to put "" somewhere in the UI And if it's from user, i would like to put something like "user INI is in use". The reason it's an annoyance for me, and I could see it being an annoyance on a user is that... some operations of JPEGView save a user INI... and just like in the case of suggestion-2, if I change a global default, or fixed a bug, say the fix in #12 ... a user might say "it still doesn't work for me" not realizing that the setting is overridden by the user-ini. Based on the complaints "extracting JPEGView overwrote my INI", I would say there's a good population of people who just use the global INI. (I do in my own use case!)... and every now and then I accidentally save a setting and then all my customizations stop working. |
Beta Was this translation helpful? Give feedback.
-
Glad you like the ideas! I didn't realize that renaming one file would mean that significant of a change. I understand that this has to be done "once and right". Which brings me to another (unrelated) idea which would probably have to be done in the same update if you were to consider implementing it. I was thinking that it would be nice to make a very small change to the app's name: Change It's a subtle change, but from a psychological viewpoint it makes all the difference between appearing as a "random password" (some unpronounceable combination of letters and cases in random order) and: "two familiar words". I think this will make app's name easier to read and to remember, less 'geeky' and more accessible to an average user. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
That one is a bit trickier... I'm not quite on board with that change. If anything, I would have renamed it to This sort of goes in line with your suggestion of renaming the app too... I saw a comment on Reddit that had said that too... a rename would make the new version "stand out" from the old version... but I'm not quite on board with that either lol... I think it's easier to get discovered by keeping the exact same name as the original project... and without renames, it becomes a "drop-in" replacement for all existing users, and they wouldn't know the wiser. New users just see a version continuation, and wouldn't notice who released it anyways... I don't shy away from the fact that this is a fork, and that for the most part (except for like the INI change, and the KeyMap changes) it's pretty much backwards compatible. I probably will change the version number to 2.0.x when the INI changes though, to signify an incompatibility. |
Beta Was this translation helpful? Give feedback.
-
Now I understand what you mean! I like the idea of displaying which ini is used in the title bar, but only if it is optional and not enabled by default. Imho, it is too much technical information for the average user. The "About" box is a perfect place for this, and should display this information anyway, but it's not very suitable for the purpose of "quickly seeing which ini is loaded", since it requires too many clicks and aiming to open and close. A greyed-out menu item would be the best place imho (and can even show additional useful information like version number: For now, maybe show it on top of the menu, but only on Ctrl+RightClick? |
Beta Was this translation helpful? Give feedback.
-
|
All good ideas... thanks for brainstorming with me... I'll keep it in mind. That menu has grown to be ... way too much. That's another thing that has to be reworked ... lol, the list is long... I'm busy the next few weeks though, so, I pushed out the 1.1.44 release first so I'll see when I can incorporate some of this. the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for letting me participate :-) I would argue that "Default" should be preserved for values the software has been shipped with. |
Beta Was this translation helpful? Give feedback.
-
|
Added idea 4. |
Beta Was this translation helpful? Give feedback.
-
|
that "header", the one with the brackets is a section header... that can't be changed. ... not easily at least. JPEGView code reads each INI and only values from the |
Beta Was this translation helpful? Give feedback.
-
Hello @sylikc, you have mentioned a couple times that you are thinking on improving the current powerful but confusing situation with two JPEGView.ini files. I am thinking about this too, and wanted to share a couple thoughts on the matter.
Rename user-ini config file in AppData to something like
JPEGView.User.ini.I think this will remove a lot of confusion for new and existing users, especially when making backups and porting preferences to another computer or a new installation.
=globalvalue for all settings in user-ini file by default.Currently, when user creates a user-ini file from Settings/Admin > Edit user settings menu item, all settings from the global-ini are copied over to user-ini, even if that user only intended to override a single setting. As result, global-ini becomes totally rudimentary for that user, which adds to confusion and potentially unpredicted behaviors.
Moreover, this makes it harder to distribute new features or improved defaults in new app versions to different users.
What if all settings in the freshly created user-ini file were to be set to
=globalvalue, thus falling back to global-ini unless user intentionally changed that particular value in user-ini?I'm not sure though whether this will simplify the debugging process, or make it even more complicated.
Alternatively, user-ini could be created empty by default, and only contain differences from global-ini (manual edits and auto-writes).
This is something I already do manually — my user-ini only contains about 10 lines, making backup process and transferring preferences a lot easier without messing with global values.
The problem with this approach is that it will be harder for users to change user-settings, since they will not be presented with a list of all available options when opening empty file.
The upside is, that user-ini file will be much less "desynchronized" with the global-ini file over time, since you are adding new ini-settings with every release, and sometimes changing defaults. Another big upside I already mentioned: ease of backup and porting preferences.
[EDIT] Add useful information to the header of ini-files.
Something like:
[JPEGView 1.2.34 - USER SETTINGS]App version number that created the file would be useful for troubleshooting, and signifying whether it's a user-ini or a global-ini right next to
[JPEGView]title would not hurt either (I know it's written in comments directly underneath, but it's kind of hidden within big chunk of text).I hope you find these ideas of some added value.
Beta Was this translation helpful? Give feedback.
All reactions