#1567 No vertical scrollbar, no horizontal autoscroll while maximized on KDE 5

[D. Michael McIntyre]

While editing inside a standard size window, I hit the maximize button and attempted to drag a segment past the end of my currrent editing window. No autoscroll occurred. The vertical scrollbar is also missing. See screenshot.

I figure you worked on all of this way more recently than I have, and may have a clue what to look at. If you need me to investigate, I can do that eventually. Back to work on this project in the meantime.

[D. Michael McIntyre]

It looks like when maximized the window geometry is just plain wrong. I expect the scrollbar and right edge of the window frame are still there, they're just off screen. I have a single display at 1920x1080 I guess.

While looking to confirm my display resolution, I realized that glxinfo is returning errors and I don't have the graphical acceleration stuff enabled. I probably never enabled the NVIDIA drivers after my distro update, and since I don't play many games, I hadn't noticed until just now. This may be impacting Rosegarden. I should try running in "safe mode" perhaps.

KDE system settings is crashing at startup, and all my GLX stuff is broken. Okay, maybe I just have a stupid local config issue. Will report back after I get this sorted out. I haven't rebooted for the last 30 kernel updates or something stupid, so I should probably just do that first.

[D. Michael McIntyre]

Let the record show that I rebooted and spent hours in update hell before giving up and doing a format/install of Kubuntu 18.04.2. After it was all said and done, the issue in question persisted. I'm not imagining it then.

[Yves Guillemot]

I confirm this bug.

I just try running RG 18.12 on Mageia 7 - beta 2 which comes with KDE Plasma 5.15.1, KDE Frameworks 5.55.0 and Qt 5.12.1.

When not in fullscreen, the RG window has a border which can be used as a handle to resize it.
When the window is maximized, this border is no more needed and is removed. That's why the window seems to continue beyond the edge of the screen.

There is no vertical scrollbar because it is not needed as the 32 tracks are fitting inside the maximized windows.
This scrollbar comes back if some tracks are added.

The autoscroll doesn't work when a segment is moved to the right of a maximized window without vertical scrollbar.
As soon as there is a border on the right of the windows (when the window is not in fullscreen or when the vertical scrollbar exists) autoscrolling to the right works.
There is no problem when moving a segment up, down or left because there is always some border in these directions.

I presume a way to fix the bug should be to add a very narrow margin on the right of the window.

[Yves Guillemot]

Back on my current usual distro (Mageia 6), I discovered I was already using KDE 5 without knowing it (probably I knew it some time ago then I forgot it :-( ) : KDE Plasma 5.12.2, KDE Frameworks 5.42.0 and Qt 5.9.4.
The behavior of the maximized window is the same and the same bug can be reproduced.

There is two screens on my system.
When the maximized window is on the right screen, the cursor can't be moved beyond the right of the window and autoscrolling doesn't work.
When the maximized window is on the left screen, the cursor can be moved on the right screen, beyond the right of the window, and autoscrolling works.

[Ted Felix]

I cannot reproduce this in Ubuntu 18.04 with GNOME and Ubuntu's Qt 5.9.5. All is working fine. KDE issue? Qt issue? Can you guys find an older version of rg that doesn't have this problem? That might provide a clue.

[D. Michael McIntyre]

The critical difference is that Rosegarden used to have horizontal and vertical scrollbars in both sections of the main window that were always on, as far as I can tell. At some point in 2017--I didn't track it to the exact change--this behavior changed to one in which scrollbars are off unless needed.

The new scrollbar behavior is fine. I just discovered a weird side effect. When there is no vertical scrollbar on the segment canvas, autoscroll doesn't work when dragging a segment. I'm also seeing some pixel level weirdness with the window size when maximizing. Sometimes it gets just a bit wider than the actual desktop viewport by a few pixels, such that the (x) close button is partially masked. Not funtionally harmful and not worth sorting out IMHO.

Yves probably has the right of it that adding a little padding would address this. In the meantime, the workaround is to add tracks until you get a scrollbar, which is easy to do. I wish I had thought of that before I wasted many hours of what could have been music creation time, but mostly that was Kubuntu's fault. That's why I usually don't even bother to try to do LTS to LTS upgrades. This was deferred chaos from whenever I did that.

[Yves Guillemot]

This is definitly a RG bug.
It appears somewhere between 16.06 and 17.04.
Attachments show the up right corner of a maximized window without vertical scrollbar with these two versions.

[D. Michael McIntyre]

I vaguely remember one of the commit messages mentioning something about cleaning up spacing and padding. There used to be a setMargin(5, 5, 5, 5) or something to that effect in tons of places. I guess whether it's a bug or a design improvement is debatable, but in any case it seems like this autoscroll breakage is an unforeseen consequence of that choice.

I tried searching for the exact commit, and I'm not coming up with the right keywords. This extra 10 or whatever vertical pixels is probably why a 32-track composition now fits my desktop without a vertical scrollbar, when it didn't in 2016 and older versions. Visually, I don't think it's wrong to remove the thick black outline, which doesn't really add anything that is a major delight to the eye. Functionally, putting it back is probably the quick way to address the autoscroll behavior malfunction.

[Ted Felix]

Ah. I get it now. Sorry I wasn't following there.

It looks like Chromium handles this by moving the autoscroll area slightly inside the viewport. This is easily done by adjusting the auto scroll point in RosegardenScrollView::doAutoScroll():

// Pull it into the viewport slightly in case there is no scrollbar.
const int xMax = viewport()->width() - 20;

// If the mouse is to the right of the viewport
if (mousePos.x() > xMax) {
    // Set the scroll rate based on how far outside we are.
    scrollX = lround(distanceToScrollRate(mousePos.x() - xMax));
}

[Ted Felix]

Just pushed the above as [r15462]. It can be tweaked if needed.

One obvious issue would be HiDPI. 20 pixels probably isn't enough. Maybe the width of an "X" character or the width of the scrollbar would be better.

[D. Michael McIntyre]

That works great at 1920x1080. You're quite right that it would be great to test this and more at a more modern resolution. Which raises the point that one of these days somebody is going to have to remake 1,000-odd icons so they perform adequately in a modern environment.

I'll start thinking about that. It will take me forever to get them all done, but I can go in stages and take a couple of years if that's how long it takes.

[Ted Felix]

One final tweak in [r15464]. Now the auto scroll area on the right edge moves inside the viewport as the viewport gets closer to the right edge of the screen.