IanSav wrote: ↑Fri Sep 14, 2018 00:54
How hard would it be to have the pause location default to the centre but to allow the user to specify the pause point? Perhaps a positive number to set the location relative to the start of the window and a negative number to set the location relative to the end of the window and zero to indicate the centre of the string.
I think it would be better to have a number that is used relative to each edge, depending on direction. E.g. if it was 25%, then the cursor would remain 25% from the left when moving towards the start and 25% from the right when moving towards the end (ignoring bidi...). That option would solve both methods - my preference would be 50% and prl's would be 0%. It doesn't help with the hybrid option - perhaps negative could be used for that? E.g. -25% would scroll both cursor and text. Or just have another setting. Or don't worry about it. Yeah, might not worry about it. Your "pause location" would be simpler to implement, but I think it would be weird if it was set near the left and you were moving to the end (I had just that scenario during testing).
It would be great if this pause position could be specified in the skin so that the window size, pause location and text alignment can all be specified in the same place.
It should also be a global option, somewhere in GUI settings? Any ideas for a name? As a skin parameter
pauseLocation works fine for me, or maybe
cursorPause. Straight number would be pixels (
"100" means stop 100 pixels from the edge), or with a percent symbol to set relative to the size (
"50%" means stop in the middle). Or maybe the skin only needs pixels? The option would only be percentage. As for option name, how about "Cursor scroll position"? Description: "Once the cursor is at this position it will remain there as long as possible, with the text scrolling around it."
prl wrote: ↑Fri Sep 14, 2018 11:23
One problem is that with these changes, scrolling in both
Input and
ConfigText widgets works in two different ways, depending on whether
visible_text is set to 0 or not. If
visible_text is 0, scrolling is adoxa's "keep the cursor in the centre and scroll the text", and if it is non-zero, it's "only scroll the text if the cursor would become non-visible".
I am aware of the difference in scroll behaviour (even more so, as I have another patch to scroll by five characters at a time, so moving through a timer description was so slow). That's a reason to remove most uses of
visible_width.
prl wrote: ↑Fri Sep 14, 2018 11:28
I'd also like to suggest that the part of the changes to elistboxcontent.cpp that stops the value in ConfigText from overwriting the label be done in a separate commit. It's a change that is worthwhile doing independently of any change in text scrolling.
Fair enough, but I'd rather leave it as part of this, since it's a bit simpler to keep it as a single change.
prl wrote: ↑Fri Sep 14, 2018 12:08
I've seen an odd interaction between adoxa's scrolling changes and the easy-skin-aus-hd skin in MENU>Setup>TV>EPG settings>EPG cache filename.
I'll look into it...