While it may seem as easy to implement as hard coded, it simply isn't..
Well then... 'almost as'?
Well, I think it would work to have parallel options for transitions.
Switch/Case possibly?
From memory, in its current form it requires dropping arguments and possibly even whole functions..
What do you mean?
but the real question is, does the user really need that option?
Not the user... The theme-creator(s)!
I don't think having too many options - for the 'normal end-user' to play around with - is necessary or a good idea. It should be the theme-creators responsibility to take care of the user-experience of his theme + if someone doesn't care, it would still default to the hard-coded 'default' (i.e.' Fade')! Thus it would remove glitches on almost all old themes THX to the hard-coded default (even without modifications) AND theme-creators would have a lot more flexibility.
It's just that theme-creators could create a quite unique user-experience for their theme and if they don't care about it, it would default to one of those transitions, which shouldn't glitch anyway (none and fade) in a lot/most cases!
Have you ever loaded up your og xbox w/ xbmc hit start and thought...that transition sucks I wish it were different.
Which transition? Lol
I don't remember it currently, sry.
I don't think the common user really cares about the transition so long as it doesn't cause any kind of graphical artifacts on the screen
I agree, which is why I suggest a
theme-config-entry with a default, which is either 'None'/0 or 'Fade'/1, because this would be sufficient for these things:
- It would fix most/a lot of glitching themes in Hires-Modes and even Hires-Art (because of defaulting to a less glitching mode, if the entry is not present)!
- It would allow theme-creators to create quite individual user-experiences (different transitions for various 'tasks' /page-changes)!
- It would be a base to extend up on, if someone wants to add other transitions (like 'Blend_in', 'Blend_out')
- etc.
which the current slide does (in HiRes anyway).
True, which is why I suggest (or agree to your suggestions) defaulting to a hard-coded way, but (IMO it would be great to) still have the ability to load another type of transition via a theme-config.
I do appreciate your input though, I think our opinions just differ.
I think they are actually quite similar!
I agree for your hard-coded part (the 'default') + think a theme-config-entry to override the default would be nice for theme-developers (as an addition).
I'll link Maximus32s commit anyway so you can see what I mean....and as I go to look for it gitlab appears to be having issues
... I'll post a link later.
THX, but does that change anything for it possibly being 'switchable'?
The choise of the transition is ahead of the executed code of/for the transition, so it is just a matter of calling the chosen transition, after the right one has been determined.
As for the theme-config-entry's structure:
I think something like...
'Transition_settings=In|Out'
'Transition_infopage=In|Out'
...or separate entries for 'in' and 'out' would be working out (in code, for theme-creators and end-users)!
(tl;dr)
I tooootally agree to an implementation of the fade-transition and defaulting to it (or 'None'), especially to make old themes more Hires-compatible (Art and VMode) in newer OPL-Versions, without changing/modifying the old theme.
I agree to that, because it makes the whole Hires-Feature more reliable especially because theme-creation compatible to Hires-Modes becomes a bit easier and it raises compatibility of old themes to new OPL-Versions and it's HiRes-Modes!
An
additional theme-config-entry is giving additional flexibility to theme-creators however.
