Open white-haired-uncle opened 2 months ago
I can't find a mainline example of repeating button, but I assume it's implemented using something like on_button_click. Perhaps add a new optional parameter bool use_hold (or something) that determines whether the repeating button will continue to work as before, or starting throwing a new on_button_held after X ms. This would add new functionality while not breaking existing uses.
use_hold could be implemented as optional<int>
(or similar) with the contents used to set the amount of time the button needs to be held before on_button_held is thrown instead of on_button_click.
P.S. I can see there being a "on_button_long_click" which would apply to "all" buttons (maybe not repeating_buttons though) in the future. I know I've wanted that at least once before. It's probably worth keeping the option in mind if making changes such as I've suggested above.
I think the repeating button was originally created specifically for scrollbar arrows, but Vultraz removed scrollbar arrows at some point, so it's quite possible it's truly unused (other than in the spinner definitions).
What? Scrollbar arrows? Would those be little arrows to the side of the data instead of that great big scrollbar that often doesn't fit nicely? As in the scrollbar arrows on my list of things I want to create?
(I'm playing around with the sidebar layout, in part to make room for more status icons, but as you can see I'm not a fan of the current scrollbar)
I would much prefer
< ABC >
to
ABCDE <-->
What? Scrollbar arrows? Would those be little arrows to the side of the data instead of that great big scrollbar that often doesn't fit nicely? As in the scrollbar arrows on my list of things I want to create?
The arrows go at both ends of the movable bar. Unfortunately, I think Vultraz won't accept it if you want to add scrollbar buttons, given that he's the one who removed them. (If I recall correctly, he wanted to remove scrollbars entirely, but I talked him out of it.)
Ah, I see. I want to (optionally) get rid of the bar and just have arrows (not taking up a whole row/column of their own, but sharing with their data). I suppose I should call them scroll arrows and not scrollbar arrows.
Or replace the bar with mouse wheel movements, that would work too. Which would work a lot better if mouse wheels worked in two dimensions (I bet some do, but I've never seen one). I guess that'd be three dimensions, counting the click.
That's not a scrollbar anymore… though you could probably make a [scrollbar_panel_definition]
that has buttons like that instead of a scrollbar. (Though I think scrollbar panels actually require a scrollbar, but it could probably just be made invisible.)
Describe the desired feature
In #9080 @CelticMinstrel suggests the possibility of using a step exponent, perhaps via shift-click, on a spinner button.
I'm not sure about the exponent part, or the shift click part, but I do think the repeating_button needs an acceleration option. The general idea here would be that when the user does something, it causes the repeating button to "accelerate".
On many appliances with digital clocks, when you are setting the time/alarm, after you hold the 'advance' button for a couple seconds it starts moving much more quickly. I think this would be the easiest to implement, and the most intuitive to the user. I would envision perhaps a couple steps, say after 2 seconds the rate increases to 5x the original and after another 5 seconds the rate increases to 25x (I just made those numbers up after several seconds of thought).
Using something like a shift-click instead of "after X seconds" would work as well, and provides more control to the user, but I don't think it's at all intuitive (though the author could add info to the button tooltip, that is if THEY knew about it).
Giving the author control over things like the delay and the amount of acceleration might be nice, but are probably unnecessary.
Ideally, the rate would not change (button would still cause event every x ms), but the effect would. I suspect that would be a much more complicated change, though I suppose if it is easy to add arbitrary events it could be implemented as "raise event E1 when pressed/held for up to X ms, event E2 when held for >X ms". If separate events do not pose much of a problem, I think this approach would add the best mix of ease of use for the player and extra functionality for the author.