https://bugs.documentfoundation.org/show_bug.cgi?id=172167
--- Comment #9 from Eyal Rozenberg <[email protected]> --- (In reply to Telesto from comment #8) > > 1. Avoid Format menu overflowing beyond screen height (this happens today on > > smaller screens) > > True, but maybe ... better... in this use-case... using the toolbar? Or > Right Click Context Menu? This bug is about placement of commands on menus. It's true that one can just avoid using the menu for some actions, but unless you're suggesting we delete the menu, or the Object/Shape-related commands from the menus, then the question remains: Where should these items be? > maybe the ribbon being better fitting in this use-case? This is a bug about the Menus+Toolbars (and Menus+Single Toolbar) UI modes. We can't solve issues with existing UI modes by telling people to try another UI mode... Also, the ribbon, in addition to having inherent problems, also takes up plenty of vspace, so on a small monitor one is more likely to use Menus+Single Toolbar - and the problem remains even in that case. > > 2. Avoid Format menu being so long, that it must extend upwards and hide > > other menus (this happens today even on typical-height screens, e.g. 1080 > > pixels, when the window is at maximum height; and also more likely to happen > > when users employ larger UI fonts) > > If the Format drop down being the only menu being pretty long, OK. However, > there are quite number of menu's quite populated. So auto 'auto-hide' menu > items seems more effective, if desired. But well that's controversial too.. Writer's "Tools" menu is also quite densely populated; I'm not sure anything else has that many items. Now, it's possible that something could be done about the length of the "Tools" menu as well, but whether that happens or not - it does not mean that the breakup of Format loses this benefit. As for "auto-hide" of menu items - that would be super-bad and is not an option IMNSHO. Plus, think about what this would mean: You would hide the bottom half of the menu, because it regards Shapes rather than general formatting. So, what does that result in? A Formatting menu without Object/Shapes command :-) + a button for getting the Object/Shapes half-menu. > > 4. Easier to get used to and memorize for new users > > > > this is in addition to being the "correct" menu placement - which is no > > small consideration of course. > > Well what is the implicit convention on this matter. So what what do > competitors do. I don't recall encountering a "Shape" or "Object" menu. Ah, but it's there! There's a contextual tab named "Shape Format". > Off-Topic: Having Name & Alt Text in the format menu is somewhat of a > overkill IMHO. Is it really needed having those in the menu? Is access from > the image properties dialog not enough? And if an menu item is required, 2 > entry's instead of one. And why are those opening dedicated dialogs instead > of simply Image Dialog -> Tab Options. Appears to be simpler & more > self-explanatory (UI-consistency) I think this is another effect of how a bunch of items were basically "dumped" - at once or over time - into the Format menu without giving it enough thought. -- You are receiving this mail because: You are the assignee for the bug.
