Window snapping of Musescore

• Aug 19, 2019 - 06:11

There's a benefit in being able to 'snap' windows to the left/right screen with the OS's/window manager's shortcut system, especially top and bottom, so that a tiling of two separate programs can be available to the user's view on screen when certain actions call for it. Specifically, this is useful while copying notes from a document viewer while having MS up and in focus. I've noticed that while in Linux (XFCE), my snap functions for windows which work for practically everything don't work with MS when attempting to snap top and bottom. Left and right work though. It seems that it has something to do with the fact that MS's main window is limited to a certain size, meaning that if one attempts to resize MS's window by dragging, there's a limit allowed, understandable, but that some how this limit disables the ability to snap to top/bottom of the screen.

The question is, if this is worthy of a developer's edit, is there an acceptable way someone may change this behavior without doing injury to the standard behavior? e.g., remove the window minimum sizing or make it something more like 40% (vertical) or something rather than how it is, supposing this is the reason why there's a problem with snapping to the top/bottom portions of the screen?

Has anyone else had an issue with this? To demonstrate, I cycle through snap functions: Right, bottom, left, up. It works for a file manager, libreoffice, but MS does not respond to the top and bottom as shown. Also shown at the end is the 'limit' of height size.



In reply to by Ziya Mete Demircan

Hey Ziya, I can confirm on Win10 that top/bottom snapping seems to be not implemented (Win+Down minimizes the focused window). In other windows managers though, most have this functionality (again, e.g. XFCE). I can attest that upper/lower snap position is prime for notation since it allows MS to have the same horizontal dimensions required for the palette/inspector panels to be open, only sacrificing vertical spacing which is okay since only one system at a time is needed during copying.

In reply to by worldwideweary

Post-Update: Actually, upon re-engaging the palette, a sort of "vertically extending the window downward beyond the screen limit" occurs, so the results of doing what was mentioned doesn't truly "snap" to the bottom portion of the window but extends beyond it. The palette seems to have an enforced minimum height which forces the main MuseScore window to be a certain dimension, even when after snapping has occurred.

This is all in version 3.2.3.

Tip: For those with smaller screens with a comfortable keyboard workflow, moving the window beyond the top portion of the screen instead---losing main menu items so that the top portion only shows the score and score tabs above it--is one way to get something working more functional as a workaround. This requires that special move function of a window manager rather than merely dragging by title bar since motion is often blocked by the window manager in attempting to go beyond the screen dimensions, but the result is better than having the bottom portion dangle off screen as with what happens when doing what was aforementioned because the view-port will be better acclimated with the "Pan Score Automatically" feature enabled.

Do you still have an unanswered question? Please log in first to post your question.