When a user clicks a menu, or right-clicks somewhere with a context menu, they typically expect the menu to extend downwards from the point of clicking (or from the menu name). An exception is when you're low on the screen, in which case the menu might extend fully upwards; but let's ignore that for now. A more problematic situation is when you're not actually at the bottom of the screen, but in the middle or near the top, yet - the menu has many items, and your display is not very tall. In these cases, it is sometimes the case that the menu extends both upwards and downwards, and your pointer is at some arbitrary point. Moreover, in such cases, the menu many extend onto the toolbars, menu bar, title bar and even further (although such behavior may be VCL-dependent). Some users find this behavior undesirable. While it maximizes the number of items visible on the screen, that is often not enough, and one still needs to scroll; but what's more problematic is the hiding of too much of the UI for their taste - it's disorienting and prevents the use of your "muscle memory" to locate items on the menu. These users would rather the menu extend downwards, like it usually does, with its further items accessible only by scrolling/pressing a bottom button which scrolls etc. I believe we should at least have some option to control this behavior ("greedy" upwards extension); and maybe even consider changing the default beahvior. * For an illustration with partial screenshots, visit: https://imgur.com/a/otT0wsh * For a brief discussion thread about this matter, on reddit: https://www.reddit.com/r/libreoffice/comments/1lw6isb/comment/n2cbdc0/
Aren't these pop-ups controlled natively by os/DE? Not just up or down, but left or right when expanding from exposed menu's start point.
(In reply to V Stuart Foote from comment #1) > Aren't these pop-ups controlled natively by os/DE? Not just up or down, but > left or right when expanding from exposed menu's start point. I actually don't know. It's also possible that they're partially controlled, or configurably-controlled; or that the VCL backend controls it; or that it's different among different VCLs.
Context menu expand system-controlled and for good reason upwards in case of insufficient space. Neither is this inconvenient nor can and should we make it configurable. What we need to do is keeping the menu size as small as possible (or rather at the necessary minimum) - the HIG states this. And actually I believe we do so. => NAB/INV
(In reply to Heiko Tietze from comment #3) > Context menu expand system-controlled and for good reason upwards in case of > insufficient space. Not always for good reason. See the examples at the link: There's quite a lot of space extending downwards, but because the menu is so long, the menu is rendered extending also upwards. This tradeoff is not at all compelling. In such cases, I would rather get downwards-extension and a scrolling widget at the bottom, rather than the awkward semi-upwards extend. > Neither is this inconvenient nor can and should we make > it configurable. It's inconvenient for three reasons at least: 1. It's surprising, in that it disagrees with the typical effect of (right/)clicking, where a menu opens to the side and down. 2. It moves the topmost menu items farther away from the mouse pointer, while menus, especially context menus, are typically designed to have those items closest. 3. It prevents you from applying "muscle memory" to make a selection on the menu. > What we need to do is keeping the menu size as small as > possible (or rather at the necessary minimum) - the HIG states this. > And actually I believe we do so. Of course it's nice if the menus are short enough so that this is not necessary. If your display is 1080 pixels high with 10pt or 11pt UI font, then yes, but that's not generally the case; but on smaller (though supported) displays, like my laptop's for example - this is not the case, and we don't plan on making it the case. There's also the situation where people increase the UI element size / font size due to weaker eyesight - also increasing the likelihood of encountering this situation.
Created attachment 202497 [details] The Insert menu expanded on a low-height display, hides "Insert", the toolbar and the title bar An example from the Reddit thread I mentioned. Version info: Version: 24.8.7.2 (X86_64) Build ID: 480(Build:2) CPU threads: 4; OS: Linux 6.15; UI render: default; VCL: gtk3 Locale: es-ES (en_US.UTF-8); UI: en-US Calc: threaded
These screenshots are not really informative as it needs to show the total screen size.
Created attachment 202502 [details] LO 25.2 Before-and-after expansion of Insert menu An example from my laptop. Screen height is 800, LO window covers > 80% of it (but not all of it). We see the upwards extension, plus the covering of the "Insert" menu header, and other menu headers closeby, and the title bar. Also, the left edge of the menu is to the left of the point of clicking. I wonder if that shouldn't be separated into another bug - horizontal vs vertical "grievances". Finally, note that a submenu is auto-expanded, because the mouse position on "Insert" becomes a position on the menu with an associated submenu, which is another jarring effect interrupting the user's workflow.
(In reply to Eyal Rozenberg from comment #7) > Screen height is 800 You are on the minimum of the required hardware specs.