Created attachment 121365 [details]
Proposed mouse wheel functionality to quickly resize inner IDE windows
This feature might be difficult to implement, so please take this not as request but as a non-definite idea that is probably worth reviewing.
The common LCD size nowadays is widescreen, what makes vertical space in editor a precious resource (cf. issue #209259). Actually there seems never to be enough space both for the editor window and the dockable windows under it (Output, Usages...). At various stages of work one would prefer either more space for source, or more space for the supplemental information in dockable windows underneath. The similar situation appears with the left IDE side where Project/Files view competes for vertical space with Navigator underneath.
From UEX point of view it would be desirable to provide some way of quick redistribution of vertical space between the upper windows and the bottom windows.
One option considered was providing a button near top right corner of each window that would resemble the Minimize/Restore button with the difference that the window would not disappear completely but would only shrink/expand in size. Such solution, however, is not too convenient not intuitive (it is not much better than the existing minimize/restore functionality).
A significantly more practical and intuitive solution seems to be to use mouse wheel for this purpose, as the standard vertical movement of the wheel naturally suggests what kind of shift/move to expect.
See the attachment for how this could work. The proposed shortcut Shift-MouseWheelUp/Down seems to make sense not to clash with the fix of issue #212484 which resulted in the use of Alt-MouseWheel, and not to clash with issue #214775 if it is implemented.
Shift-MouseWheelClick can be used to restore default window sizes.
Remark: in case more than one horizontal boundary would exist in IDE, the bottommost would be the best target to affect as it is the space in the bottom windows that appears to be important to enlarge at times.
The speed of boundary shift would probably be good to adjust so that one maximum continuous wheel roll (may equal roughly 10-12 single roll events) moves the boundary across most of the available space but not entirely to the limits.
For discoverability reasons it would be good to have a tooltip shown when mouse cursor rests on a respective horizontal boundary, with a message like "Shift-MouseWheel moves the boundary".
CC-ing Rich to ask for expert opinion.
Mousewheel interactions with modifier keys are sort of the "Wild Wild West" of interaction design. As long as you don't mess with the core functionality of the mousewheel, which is to scroll up and down, I don't think this is an issue. My only worry is how to communicate that this functionality exists, but I'm sure with documentation its not that big of a worry.
To wit, the windows UI guidelines state that Ctrl-Mousewheel is always for zooming. Shift and Alt are not specified for any given use.