View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008589 | ardour | features | public | 2021-02-26 10:45 | 2024-10-21 15:56 |
Reporter | unfa | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Summary | 0008589: Allow panning the timeline in X/Y using middle mouse button | ||||
Description | In many programs that feature any form of canvas, the middle mouse button can be held down on empty space to pan the canvas. I think Ardour would also benefit from such a feature. How would it work: When the user hold down MMB while not hovering over any region, the horizontal mouse movement translates to panning the timeline horizontally. The vertical movement has a dead zone and some increment before it shifts the view vertically, to avoid crazy track scrolling. On conjunction with the mouse wheel zoom this would greatly improve user's options of quickly navigating the timeline. Alternatively, a modifier key could be used to alter MMB's function to allow using pan even if the mouse is hovering over an object, as that'd be much less error-prone, Though I'd personally use panning much more often, so it'd make more sense to me to have pan be default, and moving regions vertically require a modifier key (Shift for example). What do you think? | ||||
Tags | ui, usability, UX | ||||
|
tl;dr: Configure your OS or Hardware to do that. Thinkpads do this unconditionally. Mac Systems likewise offer X/Y scrolling OOTB via magic-mouse or their touchpad. This is not something application developers should do. Efficient use it depends on the mouse or interface you have. Furthermore there are additional preferences (natural scrolling), or with some multi-button trackballs you may prefer buttons other than middle-click. |
|
I agree with the original poster. Navigating the canvas with come combination of middle-mouse and a key (personally `ctrl+mmb`) becomes natural for anyone who uses 2D or 3D graphics/cad programs. It should be more than one to one mouse movement to canvas movement (1.5 or 3) particularly in the x direction, might make sense for y to be a lower amount though. I find myself trying desperately to drag around before I end up zooming in and out a bunch just to move over a bit. On windows a different method of interaction that fulfills the same function would probably be covered by the standard middle-mouse-click action but on other platforms this would be a good feature. |
|
I would love this feature. So far this is the hardest thing for me to get used to, to not have this feature. |
|
@x42 I don't know of applications that rely on special hardware or OS configurations to do this kind of scrolling. The grand majority of creative software that has a 2D canvas of some kind I have used (both open-source and proprietary) has this basic feature of panning the canvas by dragging it with a mouse. Some of the tools are: Inkscape, Blender, GIMP, Krita, Carla, Bespoke Synth, Natron, Godot, Adobe Substance Designer, Adobe Substance Painter, Corel Draw, It seems strange to me to dismiss that need. Maybe in an alternate reality programs don't need to do that and OS can handle it, I have never witnessed that in action. |
|
I'm not really opposed to adding this feature, but since there is a better solution, that should be preferred: On GNU/Linux X11 provides this xinput set-prop $deviceId "libinput Button Scrolling Button" 2 # Using middle button. xinput set-prop $deviceId "libinput Natural Scrolling Enabled" 1 # for natural scrolling. You can get the deviceID via `xinput list` Chances are that your desktop's mouse configuration tool also allows to configure it. Search for "Auto Scroll". This will then work consistently for all UI applications! e.g. Chromium/Chrome doesn't support this by default, and in Firefox it's an option. |
|
@x42 not sure that's an equivalent "solution". I think what is being asked for here is not changing the default scroll button, but adding h-scroll behavior from a middle-button drag. |
|
@acollsen, @unfa: do you not have scroll wheels with horizontal scroll behavior? |
|
For example: If I click and hold the middle mouse button on the editor canvas I would love for the canvas to stick to the mouse pointer so i could drag the canvas around with the mouse without any delay or smooth scrolling. The Firefox auto-scroll is NOT what I mean. Try opening Inkscape for example and middle click and drag on the canvas. Blender uses Shift+middle-click I think. Thanks. |
|
I would appreciate an option to drag the view by pressing the middles mouse buttons. It would speed up the navigation through big project in my opinion. Because I'm used to it In most software I'm using like blender3d, gimp, Krita. |
|
For example: Scrolling Moussewheel could be ZoomIn, ZoomOut Pressing middle mouse buttons could be drag/pan view like in the most picture viewers. For example https://josm.openstreetmap.de/raw-attachment/wiki/Help/MapView/labels_hiding.gif |
|
I agree, MMB to traverse the timeline is a standard way for navigating in many applications, it almost feels crminal to not have it as a default behaviour. |
|
Indeed I would not want to live without my hardware providing this feature to all applications. |
|
@x42 this has nothing to do with hardware limitations, this is purely software. A software developer needs to program what do with the event recieved from the the user when holding down the middle mouse button. In the case of Ardour, the timeline needs to pan. As it is right now Ardour simply treats the middle mouse button as a regular click simmilar to the left mouse button as stated in their documentation https://manual.ardour.org/introducing-ardour/basic-gui-operations/using-the-mouse/ |
|
I have zero interest to implement a feature in software which ought to be implemented in firmware/hardware (and or OS level). The vast majority of system (and all systems that I have worked with with in the last 25 years) support this out of the box. |
|
Here (thinkpad) middle-click is handled differently from pressing and holding the middle mouse-button, which then starts to send X/Y scroll events. |
|
So you're saying things are working as intended when using a Thinkpad? iirc holding down a middle mosue button sends scroll events when using a regular mouse as well, why would a Thinkpad be different I wonder? |
|
@x42 It still feels clunky with a trackpad (MacBook) in my opinion. It would be great if there's an option in the settings, so the user Could set the middle mouse button behaviour by him self. It would be a workflow improvement for many who have a regular mouse. |
|
I use a regular mouse. I haven't had a mouse that doesn't h-scrolling in two decades or more. |
|
I agree that being able to click and drag with the middle mouse button to move around the editor and maybe even the mixer would be ideal. IMHO since (if I understand it correctly) at the moment it doesn't have any crucial functions, the middle button could be used to 2D pan regardless if you're clicking on a region or empty space (I wouldn't want to hunt for holes between regions, that kinda defeats the purpose). A few examples off the top of my head, Kdenlive, Gimp, Krita and Ocenaudio do this, Blender kinda does too (with shift, otherwise it rotates in 3D space). It's very much muscle memory for me, I always find myself trying to middle-click and drag in Ardour but nothing happens :) As yeenking said, perhaps this could just be an option for those who like it. |
|
@paul @x42 And it would improve the midi workflow too. for example if you work with midi, you have to enlarge the tracks. Let's say you have 3 large tracks on your screen, the actualy scroll Method sticks to whole tracks. But if you could allow to display 1/3 or 4/5 of the track paired with the ability to drag the view. In my opinion you would be much faster at midi edits, compared to scroll up, scroll left, rearrange the size of the tracks you want compare. |
|
partial-track scrolling is a totally separate question. We don't allow that now, and changing that has nothing to do with whether the scroll is driven by a scroll wheel , mouse button, scrollbar, OSC, or whatever. |
|
After going through many programs recently to see why there is confusion, I've come to the conclusion that it's not just "scrolling" the track but "grabbing" and moving. A middle mouse click acts much like a touchscreen being held down. When the middle mouse is pressed and held, it creates the anchor point at the location of the press and responds by allowing you to drag the view in all directions from that point, including diagonally, not just horizontally or vertically. All graphic programs allow grabbing, but not all DAWs do. Programs like FL Studio, in both their piano roll and track view, allow grabbing and moving, but it was developed that way from the start. Reaper does not allow grabbing in the track view, but it does in the piano roll, and LMMS does not allow grabbing anything anywhere. I'm only chiming in with this bit of information because I think some are confused about what is being asked here. It's not just scrolling; it's about grabbing and moving the view. Now, in Ardour's case, I understand why this may not be feasible, and I'm totally fine with using "Shift + Scroll Wheel" to scroll horizontally. However, I understand why people expect this behavior in their programs as well, and for some strange reason, it "feels" like it should be the default behavior. I'm not sure why though, maybe it's because MIDI editing is done in the track view? Either way, I hope this helps clear things up a bit. |
|
This is getting repetitive, but just to reiterate: almost all mice with a scroll wheel also offer, at the hardware level, horizontal scrolling. If you have such a mouse, there is no need to press shift, just do whatever the mouse requires to generate h-scroll events. I have a Logitech MX Master 3 and it goes even further: it has a separate dedicated wheel for horizontal scrolling. But that's not necessary - even the cheaper older mice that I have lying around can do h-scrolling by just pushing the scroll wheel left or right. I appreciate the distinction between "grabbing" and "scrolling" (even though at the code level there is no difference). |
|
I have never owned a mouse with horizontal scrolling unfortunately, and my current main mouse, a gaming mouse (Glorious Model O) also does not have horizontal scrolling, I guess that is why Shift + Scroll wheel shortcut exists in the first place. |
|
I would love this feature. Currently my scroll wheel (which does not have h-wheel) is quite slow, which makes doing it the Ardour way of ctrl/shift + scroll quite painful. I've tried imwheel to speed up scrolling, but that is buggy and not worth the trouble. Alas, I'm in the process of ordering a new mouse, but either way middle click to drag is pretty standard in DAWs. |
|
> at the hardware level, horizontal scrolling. While I understand what you're saying, that still wouldn't be the same thing. It's just another extra step to pan through the workspace; still on one axis. And while my previous mouse did have horizontal scrolling I'd still think it's more intuitive to pan in both directions simultaniously as you "drag" with middle mouse click. Personally I have zero desire to scroll in each axises seperately. It's clunky. Whether it's provided on a hardware level or by the included mouse software won't change that. I don't know what natural scrolling is though so can't speak on that. Because most software I use do have this feature I fumble navigating Ardour. This feature as an option would be greatly appreciated. |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-02-26 10:45 | unfa | New Issue | |
2021-02-26 10:45 | unfa | Tag Attached: ui | |
2021-02-26 10:45 | unfa | Tag Attached: usability | |
2021-02-26 10:45 | unfa | Tag Attached: UX | |
2021-02-26 11:41 | x42 | Note Added: 0025558 | |
2022-02-18 03:31 | Thovthe | Note Added: 0026332 | |
2022-07-26 19:24 | acollsen | Note Added: 0026524 | |
2022-07-26 22:18 | unfa | Note Added: 0026525 | |
2022-07-26 22:48 | x42 | Note Added: 0026526 | |
2022-07-27 15:12 | paul | Note Added: 0026527 | |
2022-07-27 15:13 | paul | Note Added: 0026528 | |
2022-07-28 07:49 | acollsen | Note Added: 0026530 | |
2024-02-07 10:51 | yeenking | Note Added: 0028486 | |
2024-02-07 11:35 | yeenking | Note Added: 0028488 | |
2024-07-22 18:21 | inc0der | Note Added: 0028826 | |
2024-07-22 18:30 | x42 | Note Added: 0028827 | |
2024-07-22 18:36 | inc0der | Note Added: 0028828 | |
2024-07-22 18:49 | x42 | Note Added: 0028829 | |
2024-07-22 18:52 | x42 | Note Added: 0028830 | |
2024-07-22 19:04 | inc0der | Note Added: 0028831 | |
2024-07-23 07:09 | yeenking | Note Added: 0028834 | |
2024-07-23 13:54 | paul | Note Added: 0028835 | |
2024-07-24 00:32 | Reezlaw | Note Added: 0028837 | |
2024-07-24 12:47 | yeenking | Note Added: 0028842 | |
2024-07-24 14:11 | paul | Note Added: 0028843 | |
2024-07-24 14:34 | inc0der | Note Added: 0028844 | |
2024-07-24 14:45 | paul | Note Added: 0028845 | |
2024-07-24 16:39 | inc0der | Note Added: 0028846 | |
2024-09-13 06:07 | ideologyheadcount | Note Added: 0028976 | |
2024-10-21 15:56 | Sidar | Note Added: 0029064 |