LO Writer currently has the following main menu items: File | Edit | View | Insert | Format | Styles | Table | Form | Tools | Window | Help I submit, that the creation of forms and form control, in a document without forms to begin with, is niche enough, that it does not merit its own main menubar item, it's own top-level menu. Instead, I suggest that the menu become visible under any of the following conditions: 1. Activating it, using a checkbox to be placed in one of the other menus (e.g. Tools) 2. Having made a setting in Toos | Options... to always have the Forms menu visible 3. (Perhaps) opening a document which has forms/form controls, in non-Read-Only mode What say you?
Maybe make it visible if the Design Mode is enabled? And move this item to the Edit menu.
(In reply to Heiko Tietze from comment #1) > Maybe make it visible if the Design Mode is enabled? And move this item to > the Edit menu. That's one possibility, certainly. It might fit near the 'Edit Mode' menu entry.
I also assume that "Form" is rarely used. Does it make sense to create a conditional logic for its activation at the top level or is it better to group it into another menu (e.g. insert)? Conditional logic seems tricky to test and maintain. I remember that in some update several top level menu points were added (I guess, form was among them). Do we know what triggered the changes back then?
(In reply to jan d from comment #3) > I also assume that "Form" is rarely used. Well... rare for most users, but frequent for some users. And the same goes, I suppose, for some other features on our menus. > Does it make sense to create a conditional logic for its activation at the > top level or is it better to group it into another menu (e.g. insert)? I'm not 100% sure. I would want people who actually use the menu to chime in. It might, because: 1. It's not a small menu, and has some submenus as well. creating a very large submenu of Insert, with a third-level menu, seems rather unwieldy. 2. The original designers of the menu wanted it to exist, and found it useful. I don't know that their considerations are invalid (and would like to understand what they were, a questio you've also brought) . > Conditional logic seems tricky to test and maintain. Is it, though? There are lots of menu items whose state has conditional aspects, like being toggled or not, grayed out or not... why not also the aspect of being visible or not.
We discussed the topic in the design meeting. The menu was introduced to align the number of root items across different modules, IIRC. Another long list of items that might be worth to show is the Shapes. And while we may show one of the two conditionally like "View > [ ] Show Forms Menu" or "[ ] Show Shapes Menu" this is would be quite uncommon. And changes to the main menu are very unpleasant for the users. So without a very good reason we better not change the default (customization is always possible).
Our agreement at the meeting was on WONTFIX.