"Universal" workspace panning

[yohannd1]

This PR adds the ability to pan through the workspace without having to click on free areas (i.e. the background). This is done primarily through holding Alt-S and dragging the area around (optionally clicking), but I've also put scrollbars back.

2026-02-24.universal_panning_demo.v3.mp4

KNOWN BUGS:

• Sometimes maximized subwindows have a wrong size until either the main window is resized or the subwindow itself is closed and reopened.
• Panning via Alt-S-Click sometimes stops working (haven't managed to track down the cause yet).

When testing, keep an eye out for whether the scroll bars are working properly and whether panning feels natural, or if it's error prone.

(Old) progress

• Initial implementation
• Change keybinding: Ctrl+Alt -> Alt+S
• Fix offset bug (at 0:12 in the video)
• Add checks to prevent dragging in odd situations (at 0:16 in the video)
• Fix bug where panning without the keybinding, finishing and then trying to drag a widget is causing weird issues. Usually it tries to resize the widget.
• Implement scrollbars
• Fix scrollbar twitching (it glitches out sometimes, specially when going to the top/left while the screen is not maximized)
• Put scrollbars in the correct position (vertical on the right, and bottom one with the width of the workspace widget itself)
• Fix maximized windows being messed up (introduced by 8d333a4)
• Fix scrollbars appearing when a window is maximized
• Fix wheel-scrolling on the scrollbars (it does nothing, but changes the scrollbar value) - fixed by 27ecfdf
• Fix bug: 1. open automation window (maximized); 2. open piano roll window (maximized); 2. close piano roll window; then the song editor will be focused. It shouldn't, and messes up panning - fixed by aca8480
• When loading a project, song editor will go over other windows. How to avoid that? Or at least remedy it. If the piano roll is maximized and open, for example, the song editor goes over and things get confusing. Not necessary for this PR

[szeli1]

My concern with this PR is that it looks like to me that other "ctrl + alt" mouse shortcuts may not work because of the event filter. I did not test this PR.
Here is some code that may be effected:
AutomationEditor:

}
else if( we->modifiers() & Qt::ControlModifier && we->modifiers() & Qt::AltModifier )
{

ClipView:

bool ClipView::unquantizedModHeld( QMouseEvent * me )
{
	return me->modifiers() & Qt::ControlModifier || me->modifiers() & Qt::AltModifier;
}

PianoRoll:

void PianoRoll::dragNotes(int x, int y, bool alt, bool shift, bool ctrl)

[yohannd1]

Changed the keybinding to Alt+S, which (as discussed on discord) is not perfect. I'm hoping to find a better keybinding in the future but for now I'm leaving this one, which I believe doesn't have any conflicts.

Also a note to self: adding the keybinding handling on the event filter is sadly necessary, as when it is pressed I have to prevent it from being forwarded to other elements. I tried implementing it with key{Press,Release}Event and it was a mess.

[szeli1]

Also a note to self: adding the keybinding handling on the event filter is sadly necessary, as when it is pressed I have to prevent it from being forwarded to other elements. I tried implementing it with key{Press,Release}Event and it was a mess.

If I remember correctly, there are other options like implementing it in MainWindow::KeyPressEvent, or by using QAction with a shortcut in MainWindow, but event filter may be the best option.

[szeli1]

I did not test this PR.

[yohannd1]

Update! I've found some bugs introduced by this PR and reported them on the PR description. They are not critical (they are not irreversible) but they are a bit annoying sometimes.