XmlSerializer & Visitors

[cybercop23]

Per discussion, starting work on changing the XML export/import to the new XmlSerializer (should it be Serialiser?) and Visitors support.

Took the original work for base model and MHAdv and added the rest of the parameters for the default models (WIP).
We'll run though a few on our own RGBEffects files to make sure no parms are missing.

@AzGilrock is this what you are loooking for - please say yes.. took me like an hour :)
Also, I haven't looked into, but assuming the vars can be anything at this point vs the actual variables used in the code...

[AzGilrock]

Yes that looks like the general idea. Before anything gets commited I need to double-check it against the branch I already have in progress that has already updated that file. I had already created some of that stuff. It gets hard to have multiple people trying to make these changes. One of the biggest hurdles is adding all the missing variables to the model class objects and having getters and setters for the XmlSerializer to retrieve and set the data.

Regarding naming....I named it first so we get the American spelling. :)
https://learn.microsoft.com/en-us/dotnet/api/system.xml.serialization.xmlserializer?view=net-8.0

[cybercop23]

Yeah.. it gets hard when several folks work on the same part. If you want to check in what you have.. I can try to figure out how to merge it and then I can do teh rest of the grunt work (that's all I'm good at). From my understanding we can/should be able to just merge it in main as we add things, so long nothing uses it, we shoudl be fine. Then it may be easier to manage updates.

[cybercop23]

#4521 (comment)

[cybercop23]

#4521 (comment)

[AzGilrock]

You said we were crossed but I was reading everything and thought we were fine. You told me to check in what I have so now I was just waiting for you to merge into that.

Our first step can be to get all the import/export stuff working. The next part is harder which will be starting to remove everything that relies on ModelXML. So like inside every model where it handles parameter changes we should be able to switch the code to just assign the model's own class variable instead of doing a DeleteAttribute and AddAttribute operation. I expect it to all be faster in the end because all these XML operations with strings can't be fast. The import/export can be done one model at a time. The next step I'm not sure can be done in pieces because once you stop updating the ModelXML object for a model then everything in the program that relies on retrieving model state from the XML will need to be updated. I did a search on ModelXML and I think its in like 3,000+ locations.

[AzGilrock]

I have 2 other things I'm trying to knock out this weekend then I'll be back on this effort. I'm working on adding a Dimmer tab to the MovingHead effect panel and I need to do something to deal with mapping the head locations during import.

I have a branch called "ban_xml" that I'll get pushed. Its basically everything I checked in last night minus some of the parameter work in ArchesModel I had already started to work on I left out since that part needs to be completely done before pushing to master.

[cybercop23]

No, no no... sorry. Meant crossed postings. We should keep the xml stuff here, not in the alias PR... :)
I agree.. my goal for today is to look over the arches changes, and get the full import/export worked out. Then like you said, I think we can do all models next.
Need to figure out something with my VS... acting stupid after I pulled all the recent changes last night and now it "thinks" they are my changes.

[AzGilrock]

I used to use GUI's and such to work with Git but after getting on a project at work where I had to learn everything from the command line I like doing everything that way now. I feel like I have better control over what's going on when I do command line Git. Like if you were working in a branch I'd do:

1. Checkin all your changes locallly for your branch:
   git add *
   git commit -m "add comment here"
2. Update your master branch
   git fetch (this pulls all remote information for the repo)
   git checkout master
   git pull
3. Switch back to your branch and merge with master
   git checkout your_branch
   git merge master (then resolve any files that say Conflict in the editor)

I do lots of "git status" commands to check where things are at along the way.

[cybercop23]

#4529

[cybercop23]

So currently CandyCanes export as a Custom Model and there's no option for xLights Model. Any ideas why and more importantly with this change, can/should we change it back to native? IDK that I want to jump right into the custom model export - was trying to work down the list and just do CC next.
@keithsw1111 @computergeek1507 @AzGilrock @dkulp ?

[cybercop23]

It seems to auto create subbuffer submodels to handle the way they are layed out, even if no alternate node is defied.
However the RGBEffects file keeps it as CC.. Going to change it/assume we can keep it as native model on exports too.

[cybercop23]

@AzGilrock as part of this change, should we

1. retire wreath and convert all to cirlce (wreath is a special case for a circle)
2. change tree to only have one model, vs 3; 360, flat, ribbon?

[dkulp]

I just unpacked 33,192 crash logs from 2022 and 2023 and did a grep on the rgbeffects.xml files for 'DisplayAs="Wreath"' and found 5,899 unique wreaths. Thus, it's definitely still used.

[cybercop23]

Maybe at the least we should remove the model from the menu so only existing ones can be copied/paste but no new ones created and come back later and see if/how we can convert them?

[dkulp]

Interesting... there were 17 crash logs with a WholeHouse model defined.... Kind of crazy.

[cybercop23]

what versions of xlights? <2020?

[dkulp]

No... I only unpacked the crash logs for 2022 and 2023 (and now 2024) versions. There were only two in the 2023 versions, and those were in 2023.01. None in 2024. So over a year since we've seen a crash with a WholeHouse model in the rgbeffects.

[AzGilrock]

Yeah I had a flat ribbon tree for like 6 years. I've retired my prop but some people might still be doing flat trees.

[cybercop23]

yes, yes... just saying to change to only have one model vs the 3 now and and the type as an attribute...

[AzGilrock]

Yes it could probably be converted to an attribute. The ModelManager would need to have upgrade code to convert the model for existing sequences. Or really layouts not sequences.

[cybercop23]

@AzGilrock Arch, CC and Circles all done (may need some attribure review) and all models added, visitors added and just need to create the Deserializers for the rest. But before I do that, I'd like to be able to get the submodels, aliases, groups to pull real values. I'll draft checxk-in what I have so you can see, but I just need a hand to get to the darn models. When you look at the code, you'll be able to see what I mean.

Updating Draft PR

[AzGilrock]

Ok let me know when to look. BTW the MultiPointModel is one that is a work-in-progress so currently I don't enable the button for the user to create one. Technically you can edit an rgbeffects file and convert a PolyLine to the MultiPoint and see it work in the released version. Its basically a PolyLine where every corner is a pixel. It will be able to be used to create more accurate custom models since the positions will be floating point and not limited to grid locations. I was working on making an editor and eventually have it like David Peace's web tool for model editing and I was going to have some model auto-generation features.

[cybercop23]

Just checked them in... i ignored all headers that i added visitors thinking it will not send them, but it did, ignore those.
so really just the baseobjectvisitor has all defs and the xmlserializer