Description: If toolbar width bigger than window width, button "»" displayed at the end of toolbar; not visible toolbar's buttons can be accessed by press button "»". The same expected for main menu. Steps to Reproduce: Use small screen resolution or reduce width of window. Actual Results: Last items of main menu become inaccessible by mouse (become not visible, but still available via keyboard (for example, "Atl+h")). Expected Results: Display button "»" at the and of menu (like in toolbars) to get access to invisible items. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.5.17 (KHTML, like Gecko) Version/8.0.5 Safari/600.5.17
It's true that the menu entries just slide beyond and we can't reach them. Asking UX for help.
That's clearly not our bug. The chevron at the toolbar comes from the OS and we have to discuss this question only for self-made solutions like the Notebookbar. The same is true from the main menu, and when your OS (or desktop environment) cuts off the main menu it has to be changed there. Double-checked how Windows work: The main menu gets wrapped into a second line on ordinary programs. So please set this flag (hopefully it's that easy). -needsUXEval +needsDevEval
(In reply to Heiko Tietze from comment #2) > The chevron at the toolbar comes from the OS This assumption is wrong. The toolbar and everything associated with it is our own. > The same is true from the main menu, and when your OS (or > desktop environment) cuts off the main menu it has to be changed there. This is only true for gtk3. For Windows, gtk2 and KDE we use our own menu implementation.
Is this really even necessary? Our system requirements are 1024x768px, and the menus are fairly concise. On Windows builds, for the Standard menu with Writer (en-US) I have to reduce the application frame to 400px before the LO close document X impacts the right edge of the Help menu entry. If we need to support more documents in the screenscape available LO better to implement a tabbed document UI as for bug 37134 rather than worry about supporting users that want to reduce the application frame for LibreOffice to questionable sizes. =-ref-= http://www.libreoffice.org/get-help/system-requirements/
Following Stuarts argument the ticket is not a bug.