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

Show messages:  1-17  18-22

Ha ! Now you're missing my point, so I have to reiterate/rephrase it.

As said earlier, the potential for actual bugs caused by this setup is indeed slim, thanks to how tight and clean the development of MOI appears to be.
The main issue with the design is not there, but rather lies in the possible ways a user getting into the beta (or a new version) may behave, which, when not knowing about the shared .ini situation, can lead very quickly to big issues. The scenario as I experienced it is as follows :

- Only using one version of MOI at a time up until recently (only casually using version V2/V3 as a companion app, but now using V4 as a main drafting tool for about two years or so)
- In this context, I never had to worry or even consider the "shared .ini" situation, since this is all happening under the hood and not revealed by looking at the contents of Appdata if only one version of MOI is installed.
- Now a beta comes around, and as an experienced user I feel like contributing with bug hunting and testing especially since one of the new upcoming features is relevant to my workflow.
- Had I not realized that the *.ini was shared (as opposed to its content being migrated over), I likely would have proceeded as I usually do when trying out a beta or a new version of a software : by reverting things to near default in order to make way for some clean testing. And in MOI, the most handy way to do that is to go into the settings and to click the button to edit the .ini directly. Admittedly there is a mention of the path, but it is very easy to overlook. The *.ini opens. And now, hypothetically, I may want to wipe it off in order to let it regenerate itself as default.
- So from there, after spending a day or so playing around with the beta and stress testing it, I may want to go back to V4 for serious work (as one would do, since a beta is not supposed to be used for serious work ever).
- The result would be that all my preferences and shortcuts for V4 would be wiped. Without a backup this would mean days of having to hunt the forums for scripts, and having to manually set all shortcuts again. This isn't something I would wish on anyone :D

Now of course this has not happened because I caught on on the shared *.ini thing just in time. But having some error prevention about it (at the very least with a warning on the download page of beta versions and new versions) really wouldn't hurt, and I believe would be common courtesy for the users.

I hope this makes more sense ! (with one last note being that none of the above really matters anymore in my specific case, since I know how the system works now :D)

---

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-17  18-22