Improving movement inside workspace

[szeli1]

This Pull Request adds the ability for users to move inside the workspace without using the scroll bars.

This change allows the user to click on the workspace (where the editors are located) without clicking on a SubWindow, and move by mouse drag. I believe this improves the workflow significantly, because instead of needing to move the mouse over to the scroll bars, the user can simply click on the workspace background and move both vertically and horizontally.

As far as I know there is no Issue open referencing this feature.

[sakertooth]

Tested it and it works fine, just some code suggestions.

[sakertooth]

Hm, the build is failing (I'm guessing Carla isn't linked to lmms). Try moving the implementation of MainWindow::workspace back into the header file.

[DomClark]

Should there be a cursor change associated with panning the workspace, perhaps?

[szeli1]

Should there be a cursor change associated with panning the workspace, perhaps?

Sure! What type of cursor should be displayed? Maybe Qt::ClosedHandCursor?

[sakertooth]

Probably Qt::OpenHandCursor and Qt::ClosedHandCursor yeah.

[regulus79]

I like it. Trying it out, I feel like if the scroll limits were removed/expanded, it would feel more natural to be able to drag the view "out of bounds", instead of being capped to the position of the min/max windows. You don't have to implement that though, I'm just thinking out loud.

[szeli1]

I feel like if the scroll limits were removed/expanded

I don't know how to do this unfortunately, it seems like SubWindows resize the scroll bars when they are moved. An other method of moving exists for QMdiArea: scrollContentsBy(), but this doesn't resize the scrollarea as far as I know, and I couldn't get it to work with the scrollbars.

[szeli1]

Probably Qt::OpenHandCursor and Qt::ClosedHandCursor yeah.

I implemented Qt::ClosedHandCursor while dragging.

[sakertooth]

Curious why Qt::OpenHandCursor is not being used.

[sakertooth]

I'm also thinking this feature should be opt-in.

[szeli1]

Curious why Qt::OpenHandCursor is not being used.

I felt that it is unnecessary and could be annoying because the workspace covers 80% of the screen and the default cursor looks better in that case, but I could implement it if needed.

I'm also thinking this feature should be opt-in.

I think users could opt out by not using this feature, I believe there is no point to make this optional if it is an improvement for all platforms and I believe it is.

[sakertooth]

I felt that it is unnecessary and could be annoying because the workspace covers 80% of the screen and the default cursor looks better in that case, but I could implement it if needed.

Okay. In my opinion, not having Qt::OpenHandCursor makes it hard for people to discover the feature because its not intuitive. Users may end up still using the scrollbar because they had no idea you could simply drag the workspace. The Qt::OpenHandCursor gives the user that indication so they will know that you can do such an action.

I think users could opt out by not using this feature, I believe there is no point to make this optional if it is an improvement for all platforms and I believe it is.

Okay. However, you may believe it is an improvement, but certain users may feel differently. It's a possibility. I also think its an improvement, but I do want to avoid any complaints being sent in about it being a forced feature upon users. That probably wont happen, but there's always a chance.

Edit: Actually, I thought about it a bit more. I do agree that the feature can be opt out as well.

[szeli1]

Edit: Actually, I thought about it a bit more. I do agree that the feature can be opt out as well.

So you agree with yourself? Edit: I will add an opt out setting.

Okay. In my opinion, not having Qt::OpenHandCursor makes it hard for people to discover the feature because its not intuitive. Users may end up still using the scrollbar because they had no idea you could simply drag the workspace. The Qt::OpenHandCursor gives the user that indication so they will know that you can do such an action.

I will implement this then.

[sakertooth]

If you are not truly satisfied with the suggestion @szeli1, I think another option we can do is to keep the arrow cursor when the user is not pressing down on anything.

Then, you could use the open hand cursor when the user initially presses down on the mouse, and when dragging, use the closed hand cursor. When they stop dragging but are still holding the mouse, switch back to the open hand cursor, and when the mouse is released, move back to the arrow cursor.

You might not even need to add an opt-in/opt-out setting actually if you don't want to, as I think discovering the feature by pressing down on the workspace is enough if the cursor switches are implemented the way I described it above.

I think this is somewhat subjective ultimately, but let me know what you think of this idea.

[szeli1]

When they stop dragging but are still holding the mouse

This would require a timer, because MouseMoveEvent is only called when the mouse moved. Unfortunately I don't see why your method is an improvement and how this would help discovering the feature. (Also the Mdi windows don't change the cursor when they are moved, so I don't think it is a big problem if the workspace doesn't indicate it, the communication around this would need to change in documentation and tutorials)

Edit: please let me know if you approve this or you would rather like your idea implemented.

You might not even need to add an opt-in/opt-out

I think it was a good suggestion to add an opt out option, since it will enable users who really don't like the feature to turn it off, it will leave the decision to the user.