You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The modding support for UI skins lacks a lot of usefulness and feels really clunky when used
I still think the UiElementDocsWriter is essential for the UI Skin mod support but the table didn't really feel useful while working with it.
Issue 1: Copying the whole UI element path out of the table for every element is really cumbersome.
-> The Table should probably only contain the whole path (e.g. MainMenuScreen/MenuButton) or it should just be a link to a formatted json containing all the skinVariants so it can easily be used to start a new mod.
Issue 2: Having all states of a UI element being different skinVariants feels kinda confusing. Also having skinVariants that only take tint into account and ignore the rest is even more confusing
-> Each SkinVariant should should specify one UI element with all its states
Issue 3: Most UI elements have no way to modfiy their font and icon colors
-> This one is a really big limitation of the current version. Preferable there would be a way to define a default color that is used by all states of the UI element and a way to specify different colors for different states.
Related Issue Links
No response
Desired Solution
The json mod structure I am aiming for for skinVariants:
The big question is how to generate docs for such a structure (or the mod boilerplate of the structure itself) without being a burden for everyone working with UI stuff in Unciv (looking at the getUIColor comments in PolicyPickerScreen).
My plan would be to update existing calls to stuff like Table() (e.g. MainMenuScreen.kt l91) to use a class (e.g. ModdableTable) that is used to define default values and to generate the docs (Similar to BorderedTable.kt). For doc generation, I'm currently looking into KSP if it could be (mis)used as a feasible solution that removes regex limitations like having to pass parameters as Strings or ints instead of variables to improve the development experience.
Alternative Approaches
Well as pointed out in #11124 dropping skinning support all together would remove the need to do anything really. I'm not entirely sure if the lack of skin mods comes from no one interested in them, there not being a good example to work from or the mod support being too limiting. I think it would be sad to drop them, but I mean if no one is using it and it just increases code complexity then ¯\(ツ)/¯
Additional Context
Input welcome if UI Skins should be pursued any further or get dropped all together.
The text was updated successfully, but these errors were encountered:
Before creating
Problem Description
The modding support for UI skins lacks a lot of usefulness and feels really clunky when used
I still think the UiElementDocsWriter is essential for the UI Skin mod support but the table didn't really feel useful while working with it.
Issue 1: Copying the whole UI element path out of the table for every element is really cumbersome.
-> The Table should probably only contain the whole path (e.g. MainMenuScreen/MenuButton) or it should just be a link to a formatted json containing all the skinVariants so it can easily be used to start a new mod.
Issue 2: Having all states of a UI element being different skinVariants feels kinda confusing. Also having skinVariants that only take
tint
into account and ignore the rest is even more confusing-> Each SkinVariant should should specify one UI element with all its states
Issue 3: Most UI elements have no way to modfiy their font and icon colors
-> This one is a really big limitation of the current version. Preferable there would be a way to define a default color that is used by all states of the UI element and a way to specify different colors for different states.
Related Issue Links
No response
Desired Solution
The json mod structure I am aiming for for skinVariants:
The big question is how to generate docs for such a structure (or the mod boilerplate of the structure itself) without being a burden for everyone working with UI stuff in Unciv (looking at the getUIColor comments in PolicyPickerScreen).
My plan would be to update existing calls to stuff like Table() (e.g. MainMenuScreen.kt l91) to use a class (e.g. ModdableTable) that is used to define default values and to generate the docs (Similar to BorderedTable.kt). For doc generation, I'm currently looking into KSP if it could be (mis)used as a feasible solution that removes regex limitations like having to pass parameters as Strings or ints instead of variables to improve the development experience.
Alternative Approaches
Well as pointed out in #11124 dropping skinning support all together would remove the need to do anything really. I'm not entirely sure if the lack of skin mods comes from no one interested in them, there not being a good example to work from or the mod support being too limiting. I think it would be sad to drop them, but I mean if no one is using it and it just increases code complexity then ¯\(ツ)/¯
Additional Context
Input welcome if UI Skins should be pursued any further or get dropped all together.
The text was updated successfully, but these errors were encountered: