Window snapping of Musescore
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.
Comments
snapping options running on my system (for all apps; including the Musescore):
![rect1006b.png]( "rect1006b.png")
win10-64
In reply to snapping options running on… 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 Hey Ziya, I can confirm on… by worldwideweary
Update: When the palette workspace is set invisible, resizing using XFCE's snap functionality to the lower portion of the screen is performable. Once this has been achieved, the palettes workspace can then be made visible to continue. Weird workaround, but it does work.
In reply to Update: When the palette… 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.