-
-
Notifications
You must be signed in to change notification settings - Fork 58
Description
Is there an existing request for this?
- I have searched the existing issues
Is your feature request related to a problem?
It's been suggested that the next release could be called 4.9. Have we agreed on this?
If so, I'd like to do some more skin/color-related changes.
#3160 already brought a slightly backwards incompatible change to the colors in this dev cycle.
#4974 (which I'd like to implement anyway even if stay on 4.8 series) will bring another slight one, unless explicit action is taken to stay backwards compatible.
If we go with 4.9, I'd like to address #3159 which would rename many-many keywords.
We can just update our skins and let users update their own modifications to them. Post a script somewhere (e.g. in this ticket) that does the search-replace. Document the old values along with the new ones in misc/skins/README.txt.
Or we can easily add a backwards compatibility fallback mechanism to mc's code. mc_skin_get() could have a new argument fallback_key to be looked up within the same group if key is not found. That way old skins would keep running until we drop this compatibility (e.g. in 4.10 / 5.0). This mechanism could also help us fork colors later on without problems. (We could also add the fallback keys for some widget chars whose names were changed a few releases ago.)
A 4.9 version bump would also be a perfect opportunity to remove some legacy options: mostly #4908, along with the easier ones #4950 / #4951.
As for #4908, if the functionality is needed then we'd still need to rework the code to accept the exact same identifiers as used in skin files, without having to manually maintain the list.
Are you guys conceptionally okay with this direction?
Describe the solution you'd like
.
Describe alternatives you've considered
No response
Additional context
No response