jliljebl / flowblade

Video Editor for Linux
GNU General Public License v3.0
2.67k stars 181 forks source link

Add keyboard and mouse wheel accelerators when editing numerical values #1146

Closed schauveau closed 9 months ago

schauveau commented 10 months ago

Some plugins such as Perspective have parameter with huge intervals (e.g. the screen size or more). Editing them with the mouse can be problematic when the preview is lagging. The keyboard or the wheel can be a good alternative but the speed is very slow.

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.

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).

schauveau commented 10 months ago

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

dvdlvr commented 10 months ago

Just for info, CTRL, Shift and CAPSLOCK are already used as modifiers for playback speed (in combination with the left/right arrows) so that seems a logical choice as accelerator keys.I'm not sure if it's possible though, but if so, maybe we should also add an accelerator value in preferences, just like for playback speedSent from my phone-------- Original message --------From: Stephane Chauveau @.>Date: Tue, 23 Jan 2024, 13:19To: jliljebl/flowblade @.>Cc: Subscribed @.***>Subject: [jliljebl/flowblade] Add keyboard and mouse wheel accelerators when editing numerical values (Issue #1146) Some plugins such as Perspective have parameter with huge intervals (e.g. the screen size or more). Editing them with the mouse can be problematic when the preview is lagging. The keyboard or the wheel can be a good alternative but the speed is very slow. 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. 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).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

schauveau commented 10 months ago

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.

dvdlvr commented 10 months ago

I'm not worried about interference.I just mentioned it so everyone is aware of it and we can be consistent with accelerator modifiers.Sent from my phone-------- Original message --------From: Stephane Chauveau @.>Date: Tue, 23 Jan 2024, 13:47To: jliljebl/flowblade @.>Cc: dvdlvr @.>, Comment @.>Subject: Re: [jliljebl/flowblade] Add keyboard and mouse wheel accelerators when editing numerical values (Issue #1146) 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.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

jliljebl commented 10 months ago

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:

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.

schauveau commented 10 months ago

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 https://github.com/jliljebl/flowblade/blob/17519407fe388154702b7ed090e0f1a2ed5a7484/flowblade-trunk/Flowblade/propertyedit.py#L297 is enough to enable 'paging' on all properties controlled by a simple slider.

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))
jliljebl commented 10 months ago

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.

jliljebl commented 9 months ago

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.