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

Show messages:  1-11  12-22

Hello Michael !

Overall I can understand most of the above in terms of straightforward ease of use for the user ; but I can confirm that a shared *.ini between different versions makes me feel very nervous. Not necessarily because of MOI doing it, but moreso because I've been trained (so to speak) as a user of other software to never ever attempt that sort of things, as this could mean that a higher version (V5) could possibly modify the .ini in a way that would make it unreadable by a previous version (V4). After all, a beta is by definition not a final release and to be used at ones own risk - so having a beta version modify such an important file without even a warning just seems backwards.

Now of course I am sure that these worries are not really relevant to MOI, because of how clean its development is. But this is more of a matter of principle.

Similarly, as I was diving back onto an earlier project today I was surprised to notice that even the file association got set to V5 beta as opposed to V4. Had I not noticed this thanks to my custom UI color that wasn't there I could have ended up saving over my work file and possibly not made it compatible with V4 (again following the motto that a beta should never ever be used for important/client work). Of course I am not saying that this caused any loss of work or anything like that ; but it does go against "good practices", so to speak. The Blender way of doing things with a prompt telling the user that the application can take care of copying the preferences over from a previous version to the new one is in my opinion much more reassuring. After all, the beta is also an occasion to experiment and play around with things, like setting up new hotkeys to try out new features - so it modifying a shared .ini really goes against experimentation (and from there, prevents bug hunting and testing ... which is the point of a beta in the first place !).

As for the naming : well, I obviously wasn't suggesting such a long new name literally :D But, it still remains that IMHO if a choice has to be made between screen real estate, and a feature potentially taking the user by surprise (as mentioned by BemFarmer earlier), then the priority should be given on being as explicit as possible, with screen real estate being secondary to that. But of course this one detail is quite minor, and I can understand the opposite point of view too.

I hope this makes sense !

- - - - -

[edit] Case in point re. V5Beta : I just uninstalled V5Beta as to not risk any issue with my .ini ... and it turns out that uninstalling it (on a win10 machine) also removed the file association of .3dms from MOI, setting it back to ... the Rhino evaluation I had previously installed. Of course this isn't a huge deal, but that too is something that a beta shouldn't do IMHO. If anything I would say that the beta should probably not register any file association at all - after all, an advanced user trying out a beta would be able to that themselves if needed.

---

Hi Pior,

re:
> as this could mean that a higher version (V5) could possibly modify the .ini in a way that would make
> it unreadable by a previous version (V4).

If that were to happen then it would be an important bug to fix and if the beta was not set to behave like the v5 final version did the bug would not get caught during the beta test period.

It's helpful in general to gain stability and reliability by having the beta version behave like the final version as much as possible.

Suddenly switching various behaviors just after the beta period ends is a good recipe for having bugs appear in those areas.

- Michael

---

Hello !

Absolutely true regarding the testing environment needing to be as final as possible ; but I would say that since this testing does involve the potential editing of an important *ini file that one may rely one for serious/client work done with the previous version, then at the very least there should be a warning about this during beta/next version install, or a bold disclaimer about this somewhere on the download page.

Now again I understand that people should always backup their *inis, and so on. But even if a beta is by definition a "use at your own risk" kindof thing, I still think it is fair to expect precise warnings about what's going on under the hood in this case as the behavior is really quite uncommon. As a matter of fact I believe this is the first time I've ever run into this, as usually the process to get ones preference loaded up into another version of a software relies on copy-pasting the file into the user preferences folder created by the next version on startup. It being a surprise after a hundreds of hours of MOI use and *ini and UI tweaking just shouldn't be a thing, imho ...

Anyways, these are all just suggestions really as "backseat designing" is always easy :) I just hope that this may be food for thoughts.

---

Hi Pior, I'm sorry I'm just not convinced that it's a big issue, if you have put in a lot of work into customizing your moi.ini file then it would be advisable to make backup copies of it.

The current behavior is by design, so that if you install v5 (any version, beta, final, whatever) it will use the same settings as a previous version and if you do something like add in a new keyboard shortcut it will show up in all versions.

If you are very worried about it then I guess don't use the v5 beta versions. I have put a huge amount of effort into making the betas stable and usable for production work though.

- Michael

---

Absolutely ! As far as I am concerned this makes the beta not safe for me to use, but that's totally fine ; and I can certainly understand the motivation for the design decision.

All I am saying is that there should be at the very least a warning about it to inform users *before* downloading/installing the beta, otherwise it can end up being a bad surprise for experienced users who would otherwise be happy to bughunt and provide feedback on a beta version but are wary of this kind of shared *.ini situation, exactly as I am. And I'd argue that no one wants to spend time uninstalling software and setting up windows files associations (and being worried that something might have broken in the process, like potentially loosing shortcuts and scripts and having to go back to a backup if the uninstaller went a little to far) while in a rush to finish a job on time ...

Anyways ! I think that about wraps it up, both as far as this *ini topic as well as the initial topic of this thread :)

---

Hi Pior,

re:
> All I am saying is that there should be at the very least a warning about it to inform users
> *before* downloading/installing the beta, otherwise it can end up being a bad surprise for
> experienced users who would otherwise be happy to bughunt and provide feedback on a
> beta version but are wary of this kind of shared *.ini situation, exactly as I am.

A warning like that would seem strange to me.

The v5 final version will also have this same behavior of using the same moi.ini file so that
any customized settings for your environment are automatically used.

Does that mean that the final v5 version should also have a warning?

I don't know how to phrase the warning in such a way that it's not pretty weird, like
"Warning this new version of MoI will behave the same as previous versions of MoI".

A lot of people would read that and react something like "What? Why is that bad?".

In general I try to avoid baffling the user with things like that.

There has never been a bug like you are describing where the moi.ini file was
completely trashed by a beta release and unreadable by the previous version.

It just doesn't really make sense to warn about some hypothetical bug that has
never happened.


> like potentially loosing shortcuts and scripts and having to go back to a backup if the uninstaller
> went a little to far) while in a rush to finish a job on time ... :)

The uninstaller will not erase your shortcuts or scripts, that's also worrying about a hypothetical
bug that is not an actual problem.

- Michael

---

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-11  12-22