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.
Last items of main menu
become inaccessible by mouse
(become not visible,
but still available via keyboard
(for example, "Atl+h")).
Display button "»"
at the and of menu
(like in toolbars)
to get access to invisible items.
User Profile Reset: No
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).
(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.
Following Stuarts argument the ticket is not a bug.