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

Show messages:  1-20  21-22

Hello Michael,

There seems to be a minor issue going on with style assignment/coloring, in V4. The steps are as follows :

- Creating a 2D drawing in a fresh new session or file
- Performing a File>Export to .3dm
- Opening this newly .3dm file

Now in this new file, style/color assignment doesn't seem to do what it should with all lines remaining default black.

After that point, even doing a regular File > Save and reopening that, fails at bringing back the styling features. However copy/pasting the objects into a fresh new file make the styling commands operational again.

I should also mention that my usual way of assigning colors is through a custom command as opposed to using the default UI, but I don't think that's the issue. FWIW I am using this syntax :

command="script: var style = moi.geometryDatabase.findStyle( 'Red', true /*CreateIfNotFound*/ ); moi.geometryDatabase.getSelectedObjects().setProperty( 'styleIndex', style.index );"

I hope this makes sense !

---

Hi pior, I can't repeat the problem over here.

I followed your steps like this:

> - Creating a 2D drawing in a fresh new session or file



> - Performing a File>Export to .3dm

I selected the circles and used File > Export to a file test.3dm.

> - Opening this newly .3dm file

I used File > Open, and got this result:




So the problem might be something particular to your environment. Do you have any scripts working that might change the display to use fixed colors for curves instead of colors by style as it normally is?

Or do you possibly have multiple styles with the same name and you're using File > Import to open them up instead of File > Open?

- Michael

Image Attachments:
pior_styles1.jpg  pior_styles2.jpg 

---

Hello Michael,

Interestingly enough, when doing it from complete scratch just like you did everything is behaving as it should (even when using the custom command for style assignment). I'll keep digging to see if I can reproduce this more reliably. I do a fair number of PDF exports/imports too so maybe this is related ...

---

Hello again,

I think I have tracked it down : it seems to happen when a .DXF export happens within the course of a project. II still can't pinpoint the scenario exactly, but that certainly seems related. I hope this helps !

---

Hello,
After about one year of running into this issue intermittently I have finally figured it out. This is not a bug (in the sense that there is no code error or anything of the like) but rather a hidden behavior when importing DXFs and dealing with layers/styles.

I can now repro it because it has just happened to me while importing a DXF created by another person. To repro, get one of the DXF files from this project, like the Wood Control Box :

https://www.thingiverse.com/thing:797666/files

It opens up and imports just as expected. But, not only does it import the drawing, it also imports the following styles :



This of course is not necessarily an issue in and of itself. But if one decides to open this file rather than import it, then the default MOI styles will not be present in the current work scene. So if someone then saves this as .3dm the scene will not have the default MOI style colors that a MOI user may be familiar with and may rely on for organization. The reason why I didn't catch this for the longest time is because I do not have the Styles panel visible in my UI since I very rarely need to interact with it (I use buttons to send parts directly to a given layer/style and hide/show the few layers I always use for organization : default black, red, and blue).

So in a way there is nothing wrong under the hood and the workaround is easy : ctrl-c the parts, and ctrl-v them into a fresh MOI scene that has all the styles. But perhaps it would be good to have some way to re-generate the default styles directly from within the interface, since one may consider these colored styles as a core component of the MOI workflow.

Image Attachments:
2022-08-31 13_29_36-.png 

---

This different behavior for Open, versus Import, of a .3dm file, is normal. (IMHO)
Opening a third party .3dm which has a different color styles setup than a users default color styles has always resulted in only the different color styles being present in the current MoI session.
If the third party .3dm is imported, the users default color styles remain. The imported colors are added to the current session.
(This is occasionally a good way to discover a pleasing new color style.)

Not sure about the dxf aspect.

I am content with the current Open vs Import color style behavior.
But occasionally, I (very slightly) dislike missing my default colors after opening a 3rd party .3dm.
I can see how the temporary color style's "missing" might be unexpected by a user.
Should there be another checkbox to keep my color styles???
How about a script to add back my default color styles???
A new session of MoI will have my .ini default color styles.
Windows can "automatically" open a .3dm file. Which would just have the .3dm file's colors.

- Brian

ps, Yesterday I discovered that my MoI ini files for my color styles had a pair of hidden "batwing" curves, left over from an old iris project.
They had been inadvertently saved with a new MoI color .ini file. (Deleted them and resaved .ini file to AppData.)

---

Hello !
Absolutely, this is definitely not a bug and as a matter of fact one can only appreciate that the current way of handling these things (importing/opening files with styles) does respect the data of the main user as well as that of the third party user. So from that point of view the current behavior is excellent.

That said it remains a little bit awkward that one can somehow end up not having access to something that is usually there by default. Now it would make sense if such styles were only stored in the custom startup style ; but MOI also "autogenerates" them on startup somehow, so it would make sense to have a way to force this "style auto generation" action at any later time too.

---

Hi Pior,

re:
> But perhaps it would be good to have some way to re-generate the default styles directly
> from within the interface, since one may consider these colored styles as a core component
> of the MOI workflow.

There is a tool for doing that under Scene browser > Styles > "Add default styles".





- Michael

Image Attachments:
pior_add_default_styles1.jpg  pior_add_default_styles2.jpg 

---

Hi Michael,

I just got a nice surprise, and learned a bit.
Opened the file " Failed Fillet 01" file, which has 7 color styles.
Selected ellipsis, (3 vertical dots), and selected "Add default styles".
My 27 additional color styles were added.
(MoI4 and MoI5beta)
(I had assumed that default meant the standard MoI color styles.)

- Brian

---

Yeah, there are some clever things going on with the way the custom startup scene is handled, even across different versions. For instance, when launching V5 beta it will still know if a startup file has been set in V4 and will open this up on startup.

(I am actually not 100% sure if I like this or not, as that would mean that MOI is somehow storing some extra data or path outside of its config folders. Or perhaps it is running some kind of test to see if a previous version has been installed, and fills up the startup file field in the ini of the other version accordingly ? I certainly wasn't expecting V5 beta to open up with my custom startup file and hotkeys without being prompted for a transfer of .ini preferences beforehand. Meaning that it is then unclear if V5 is pulling its config data from the v4 .ini, or the v5 .ini ...).

From there I would think that these extra/user-defined default styles you are recovering are coming from your user-defined startup scene. Meaning that the feature to retrieve the default styles is perhaps slightly mislabeled, as it is not only regenerating the default styles, but it is *also* seemingly recovering the ones from the user startup scene. "Add default styles and custom styles from user startup scene" would be more exact.

---

Hi Pior,

re:
> (I am actually not 100% sure if I like this or not, as that would mean that MOI is somehow
> storing some extra data or path outside of its config folders. Or perhaps it is running some
> kind of test to see if a previous version has been installed, and fills up the startup file field
> in the ini of the other version accordingly ?

It isn't doing anything complicated like that, it's just that by default all versions of MoI use the same one moi.ini file inside the appdata\Moi folder.

It's set up that way so that if you install v5 you can just start using it and any settings you have set to customize your v4 environment will automatically be used by v5 as well.

If you want you can set things up so that MoI v4 and v5 will use separate moi.ini files. You can do that by passing in a command line parameter to MoI.exe giving it the full path to a moi.ini file to use. If there are any spaces in the path put it in "double quotes".


> I certainly wasn't expecting V5 beta to open up with my custom startup file and hotkeys without
> being prompted for a transfer of .ini preferences beforehand. Meaning that it is then unclear if V5
> is pulling its config data from the v4 .ini, or the v5 .ini ...).

I don't see why you'd expect v5 to revert to "factory default" settings instead of using the same settings you have already adjusted for v4.

It is intended that someone who is using v4 can install v5 and just start running it with it behaving similar to v4 which includes automatically using any customized settings.


> Meaning that the feature to retrieve the default styles is perhaps slightly mislabeled,
> as it is not only regenerating the default styles, but it is *also* seemingly recovering
> the ones from the user startup scene. "Add default styles and custom styles from user
> startup scene" would be more exact.

That's true that it would be more exact but it's also generally helpful for various reasons for text labels in the UI to be compact.


- Michael

---

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 

---

Show messages:  1-20  21-22