Add keyboard and mouse wheel accelerators when editing numerical values about flowblade HOT 8 CLOSED

A keyboard shortcut to reset the field to its initial value would also be nice.

from flowblade.

from flowblade.

I am no Gtk expert but it seems to me that there should be no conflict with the shortcuts defined for other widgets.
Unless things were done very strangely, the playback speed modifiers should only be active when the preview or the timeline have the mouse or keyboard focus.

If I can figure out how this is done in Gtk then I will try to code it in Flowblade.

from flowblade.

from flowblade.

It would be nice if PageUp & PageDown could add/subtract 10 times the amount of the Up and Down keys to speed up keyboard editing. This is a common behavior in a lot of tools (Gimp, Openshot, Stellarium, ...) and I find it quite convenient.

This can be done.

Currently all key down events go to keyevent.key_down(widget, event) function which returns False if event is not handled and then let's Gtk do its thing.

In the case Up and Down keys keyevent.py handles event and moves playhead to next cut if timeline has focus, see keyevent. _timeline_has_focus() method, otherwise it returns False and Gtk does increase/decrease on slider. PageUp & PageDown are also handled if timeline has focus.

To implement the requested feature one would need to:

• collect all slider widgets when edit panel is created for a filter. This is already done for e.g. keyframe editors , see _get_focus_keyframe_editor()
• test if widget is slider when keyevent.key_down(widget, event) is called for PageUp & PageDown key down events EDIT: if timeline has focus key events are handled for playhead position change
• do large add/subtract EDIT: if modifier key is down, no modifier key here.

I can take pull request or can do it myself later. If this is common behavior having it in Flowblade will be expected by some users and we should have it.

Another nice behavior, could be to use keyboard modifiers to change the speed when using the mouse wheel. For example, in Gimp the steps are multiplied by 10 with CONTROL and divided by 10 with SHIFT (when this is possible).

This is probably useful only when mouse wheel is used to scroll timeline position and not when it is used to zoom. I don't strong opinion yet on how/if this should be implemented. We are already using CTRL to switch between zoom/scroll so maybe ALT could used for the larger steps. I'll would a take pull request for this but maybe won't do it myself.

from flowblade.

It appears the only thing that is missing is a page_increment argument to the Gtk.Adjustment in AbstractProperty.get_input_range_adjustment()

So adding page_increment=float(step)*10 here

The most noticeable side effect is that the mouse wheel now works on the slider widgets (with a page increment). Before that the wheel was only usable on the SpinButton widget but with a step increment.
The slider widgets also accepts CONTROL+RIGHT/UP/LEFT/DOWN to move by one page.

Unfortunately, the PageUp & PageDown keys do not work because they are indeed conflicting with the timeline shortcuts!

However, hard-coding a page that is 10 times the step is not always a good solution. For instance, in the Distort Foldover filter the drive and skew arguments only have 10 possible values (from 0 to 1 with step 0.1) which makes the wheel jumps between 0 to 1.

Instead, it probably makes sense to adjust the page increment according to both step and input_range. So I tried the following and I am quite please with the result.

    def get_input_range_adjustment(self):
        try:
            step = propertyparse.get_args_num_value(self.args[STEP])
        except:
            step = DEFAULT_STEP
        lower, upper = self.input_range
        value = self.get_current_in_value()
        range_count = int(abs(float(upper)-float(lower))/float(step)) # number of steps in the range. 
        if range_count > 50: 
            page_factor=10 
        elif range_count > 25:
            page_factor=5 
        else:
            page_factor=1
        return Gtk.Adjustment(value=float(value), lower=float(lower), upper=float(upper), step_increment=float(step),page_increment=float(step)*page_factor)

However, I suspect that this is probably not the right location to compute the page_increment. you may also want to be able to set it in filters.xml

By the way, I noticed that the get_input_range_adjustment() methods look very similar in all derived classes. The only thing that differs is the value so it probably makes sense to move the value to another method so that get_input_range_adjustment() . The original code (without the page_increment) would then look like that and only get_input_range_adjustment_value would need to be redefined in each derived classes:

```python
    # Provide the adjustement value to get_input_range_adjustment()
    def get_input_range_adjustment_value(self):
         """
         provide the value when creating the Gtk.Adjustment
         """ 
         return float(self.get_current_in_value())

    def get_input_range_adjustment(self):
        try:
            step = propertyparse.get_args_num_value(self.args[STEP])
        except:
            step = DEFAULT_STEP
        lower, upper = self.input_range
        value = self.get_input_range_adjustment_value()
        return Gtk.Adjustment(value=value, lower=float(lower), upper=float(upper), step_increment=float(step))

from flowblade.

Did a bit of research and everyone seems to have mouse over scroll wheel slider editing, so it is clear that we should have it too.

I tested your heuristic on calculating page_increment on a branch and it seemed good, some parameters had a bit bigger step then others, but all tested were reasonable. Since the result was a working improvement I merged it into master and pushed, you can test how it works if you pull master.

By the way, I noticed that the get_input_range_adjustment() methods look very similar in all derived classes. The only thing that differs is the value so it probably makes sense to move the value to another method so that

I decided that it was easier to put your heuristic in get_page_factor() method instead, see the patch for details.

The PageUp/PageDown slider editing was only present in Gimp but would also be nice to have. I can take PR or do that myself later.

from flowblade.

I looked at the code directing key events to editors instead of timeline, and it was much more involved them I remembered so decided not to take the task on.

The mouse scroll slider editing seems to be the more established convention, so I'm happy with us having just that. I would take a PR on the PageUp/PageDown feature, but for now I'm closing this issue as done.

I added you as ' schauveau' into the developers list. You provided the code here, and in the Perspective filter thing, and the video display issue research and solution was a big help. Comment here if you would rather be referenced by real name instead of Github user name.

from flowblade.