steps: 1. open writer 2. open the File menu and notice how long it is 3. insert a chart 4. open the File menu and notice its the same length File menu is supposed to be quite small as in the xml. https://opengrok.libreoffice.org/xref/core/chart2/uiconfig/menubar/menubar.xml Version: 6.2.0.0.alpha0+ Build ID: f7e0297b01f739e17f2f9517bf3d89baaee654ab CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group threaded
I believe it works as expected. In OLE in-place editing (as opposed to opening in a separate window), the resulted menu bar is a mix of the menus of the container application and the object application. Source: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683898(v=vs.85).aspx If by a chance you have access to WinXP (because it still had menus in WordPad and Paint instead of a ribbon), you can do a simple test: Open WordPad, Insert > Object > Bitmap Image. Notice how the File menu is of WordPad, but the rest of menus are of Paint.
Is there a benefit to this approach, when the File menu has most of the entries in it disabled and for example the File > Save is to save the OLE and not the underlying file?
(In reply to Yousuf Philips (jay) (retired) from comment #2) > Is there a benefit to this approach, when the File menu has most of the > entries in it disabled and for example the File > Save is to save the OLE > and not the underlying file? Absolutely, the consistency of menus is important for good user experience. If a function is only temporary not available, which is the fact for being in Chart editing mode, than it has to be disabled rather than hidden. There is, by the way, some effort done currently to harmonize the menus over different submodules. Closing as WFM following Maxim. For me it takes less than a second to open the menu in all situations.