Full Version: issue with style/coloring after export and open

Show messages:  1-18  19-22

Hi Pior,

I have been following this conversation but have a different opinion. It seems to me that the single .ini file is both a common and a reasonable solution to save application configuration. From decades of use and administration of larger scale multi-user systems, a common settings file or directory for each user was typical. When a new version of software was installed, all users were exposed to the new features and at the same time maintained all of their personalized settings for that application. Although most modern systems are no longer really multi-user, from a developer's perspective, the task of maintaining the personalized settings as common to an application is similar: it is very important to make sure new versions don't damage the settings, but at the same time allow users to make changes that can be seen by multiple versions. In my experience using MoI, Michael has done an excellent job of providing this capability & I would hope that he would not create version specific settings files. As has been mentioned in this thread, a user does have the ability to create and use version specific settings files if they choose to do so.

As to your experience with reverting the settings back toward the defaults and testing features, I can only say that's what system backups are for, or perhaps making an intentional copy of the settings file(s) before you commence the testing. I agree with you that it would be both scary and frustrating to to have reverted the settings in the new version and then return to the old version to find that your customizations were missing. If that did happen, I suspect that your first inclination would probably be to look in your system backups.

I have very much appreciated that the beta versions of MoI use the same settings as this makes it natural to be able to test the new version. I've also appreciated that if I make a setting change in the beta, it is (within reason) also used when I use the prior version--for example a change to axis colors being usable by multiple versions. I think that having a number of settings files would end up being very cumbersome to deal with.

--Larry

---

Hello Larry !

UX is always a fascinating topic, and it's great to hear many opinions about it.

That said, while I agree with all of your points ... I am afraid that my own is being missed, again :D I am not saying that the shared *.ini design necessarily has to go (and I am in no position to request such a thing anyways !) - after all this is how MOI does things, and there are some benefits to it. And of course I do love it too when my custom tweaks and shortcuts are readily available after installing a new version of a software, as that is something that I 100% expect to happen (either manually by duplicating the file, or automatically with the app making the copy, or even, even though I am not a huge fan of it, with the way MOI does it). My point is just that in MOI, the error prevention measures around this design are lacking.

For instance a simple way of being proactive about it would be the following. It still wouldn't fully solve the issue of the unexpected surprise on startup ; but at least, any power user with hours of MOI under their belt would have come across this warning a few times during normal daily use, and this even without installing any beta or any new version - and therefore the user would have been "trained" in advance about it. As for the text : even though I agree that "less is more" in general, when it comes to keeping the data of the user safe the opposite is true : More is always best. For instance even though this popup comes from a button located in the "General" panel, it can still be used as an opportunity to warn about something related to the later "Shortcut Keys" panel.



As for what other applications do : well, this would be an argument from authority which could be countered easily by pointing out the way Blender and Unreal do things :D So I don't think it is really relevant.




And of course I understand that in the case of MOI, the best way to experiment with the beta without affecting the ini of a previous version is to do a backup of it. My whole point is that the application does not go out of its way to tell me anything about it. And even though some users may have guessed this, It is not reasonable to *expect* users to guess it beforehand. I certainly didn't realize it until yesterday.

Anyhow - at the end of the day I am just an Error Prevention Absolutist, and while I do understand that it is a bit of a strict position to hold, it is the one on the side of caution ! :D

Image Attachments:
2022-09-06 17_06_16-Blender.png  2022-09-06 17_06_46-UnrealEngine.png  ini suggestion.jpg 

---

Hi Pior, your described process is rather unusual, most people who run v5 just see their settings being used and just go ahead and use it the same as they were using v4.

I guess this has not come up often because the vast majority of people don't start out with the v5 beta by manually editing your moi.ini file and removing your customizations.

Also usually someone who wants to directly edit the moi.ini file will keep backup copies of it.

I'm sorry that you have run into this problem. But judging by the lack of similar problems over the years I don't think a warning is merited. That's because such a warning is not without cost, each chunk of text or UI that is not pertinent to the user contributes to complexity/"word salad" and makes other information a little harder to browse.

Thank you for your description of what you ran into though, it is very helpful for me to know what problems someone is experiencing. Then if I notice a trend where it's being encountered by many users that would make me re-evaluate some kind of change to avert it.

Thanks,
- Michael

---

Hi there Michael !

Well, I am glad that at the very least I've managed to make my point clear. And even if, of course, completely wiping off preferences is not necessarily the way one would go at testing out a MOI beta, it still remains that deleting preferences is a *very* widespread way of making sure that one is working with a clean slate when testing something about a piece of software. Case in point : had I reverted my UI to default before starting this very thread (about the colored styles thing), I wouldn't have reported on an issue that wasn't a bug !

And of course I have no problem with making backups, I do it all the time for a lot of different things because I can't afford losing work. All I am saying (again) is that given how very unusual it is for a Vn piece of software to silently "backward change" user settings and hotkeys in the Vn-1 version (regardless of how well designed the shared file is), there should be at the very least *some* warning about it, as I can honestly say that I have never, ever run into this behavior before. Now how to communicate it with few words and in the best possible, non-intimidating way is a side topic, and an easily solved one IMHO. My suggestion of putting it in the popup about manual .ini editing is just *a* solution (and I believe the most logical one ...), but It doesn't have to be there literally - it just has to be somewhere commonly seen enough so that any user can know about it beforehand. The next best places would probably be as a warning during the installation process, or as a warning on first launch.

Also I think that this issue not being raised so far is just a chicken and egg kind of situation. I would think that the more "advanced" users are (say, in terms of hours spent with the software, as well as overall experience with tech in general counted in years), the less likely they would be fine with the idea of settings and hotkeys changed in V5 also retroactively affecting V4. But of course no one can be concerned about it if they don't know ... just like I wasn't concerned about it until two days ago :D

Also in the specific case of MOI, it is especially likely that one may be nervous about it because the most common way to use custom scripts/commands in MOI is through assigning said commands to hotkeys saved in the .ini, as it is often instructed here on this forum. Therefore the .ini stores more than just superficial user settings, it can also contain commands that can be essential to ones workflow.

(On a side note : storing scripts as hotkeys is what I used to do for a while, up until a few months ago when it became unsustainable. Therefore I started to create custom text buttons instead and it has made my workflow much better as it removes one layer of things to remember. So another unrelated suggestion on the overall topic of UX and user tweaks, would be to emphasize this feature more, as I am sure that many users who end up assigning many complex scripts to hotkeys might not even be aware that they can create handy little custom UI buttons instead, directly in Sidepane.htm. So perhaps there could be a dedicated .htm panel (stored in appdata, and ideally ... per-version of course !) made specifically for managing custom scripts and generating buttons for them).

- - - - -

Now as previously said, I am in no position to request any change, nor I am hoping to. The spirit of my (lengthy) posts is to make my point absolutely clear and to not have it be misrepresented/misunderstood.

If anything, this could mean that perhaps user settings (like the various switches making the app behave one way or another) might have their place in a shared ini, but hotkeys and scripts might be worth storing in a different file per version, just like all other apps do.

---

Show messages:  1-18  19-22