RFC: How to deal with UiElementDocsWriter limitations

[SomeTroglodyte]

Problem Description

UiElementDocsWriter has pattern matching for explicit getUiBackground calls, but often -increasingly so- skinning code will drive that from collections or constants or some other dynamic source.

There are kludges already in place of varied nature, ~and failing uses - e.g. "WorldScreen/CityButton/InfluenceBar" is supported, but not listed in docs/Modders/Creating-a-UI-skin.md, likely due to a simple auto-formatter long-line wrap.~ _{^{(oops, that one works, the table places the last part in a separate cell so I didn't find it)}}

Potential Solution

Create a special type of comment that "client" code will include to explicitly tell UiElementDocsWriter about supported paths and defaults. I'd like it to start with /** [UiElementDocsWriter] so the UiElementDocsWriter source is only a Ctrl-B away, but then how to ensure it is not applied to a following element? Simply place at the end of the object just before the final }? (The Kdoc style could also serve to enable non-UiElementDocsWriter comment parts linking to other places)

Alternative Approaches

Drop skinning support??? BabylonUI seems to be the only skin mod left, and it's stagnant. Anybody knows an active modder in that area?

Additional Context

Places to consider:

• BorderedTable: Has its own pattern in UiElementDocsWriter, potentially to be replaced?
• AnimatedMenuPopup.SmallButtonStyle - I even think there's a bug there: === will always be false as it compares to far up in the wrapper hierarchy, the ones it needs to compare are private further down (I had a solution in some PR - add a hasUIBackground() to the skinning code)
• PolicyColors, the new one, already uses comments to fool UiElementDocsWriter
• The new HealthBar (I should finally rename it) has massive problems with this and will induce more in client code

[SeventhM]

#9633

I think @hackedpassword was looking into to it at some point, not exactly sure where that is going (not my expertise)

[SomeTroglodyte]

9633

Same construction site, different perspective. This here tries to question the architecture, that there was more about better RegExes?

[hackedpassword]

Since your regex is more like a script Trog, breaking it down into components still appears to be the best approach. Perl Monk level regex is incredible but as we see it's hardly manageable. I'm surprised the code isn't broken down into magic instanciated methods of OOP micro code like the rest of the code base.

The tools I wrote prototype a solution but they're not compatible at all with the current code. Basically a pipeline of collection and massaging data into the desired output.

https://github.com/hackedpassword/UiElementDocsWriter

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.