Created attachment 127417 [details] Command not appearing in the HUD If I type "Refresh Tables" in the HUD the command should appear, but instead it does not.
*** Bug 102267 has been marked as a duplicate of this bug. ***
I don't even get the stuff that is visible in your screenshot. Do I have to change some setting..? Ubuntu 16.04 64-bit Version: 5.2.1.2 Build ID: 1:5.2.1~rc2-0ubuntu1~xenial0 CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
(In reply to Buovjaga from comment #2) > I don't even get the stuff that is visible in your screenshot. Do I have to > change some setting..? > > Ubuntu 16.04 64-bit > Version: 5.2.1.2 > Build ID: 1:5.2.1~rc2-0ubuntu1~xenial0 > CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; > Locale: en-US (en_US.UTF-8); Calc: group No, you don't have to change any settings.
I can reproduce it. The "Refresh Tables" menu item is disabled when Base is started, because it defaults to the "Forms" mode. One has to switch to "Tables" to enable it, but the native menu state won't update until the next time the menu is activated. This used to work, but was unintentionally broken with: commit 15436c009e756dd4c94046f9849ad5a186454af8 Date: Tue Jun 7 13:31:12 2016 +0100 gtk3: move the updating of native menu to right after its activated try fix that view->toolbars isn't in sync Change-Id: I095be3003f076193878f2c3ce2a2be5acbe0e33f The problem is that the HUD implementation found in recent Ubuntu versions doesn't support activation callback, so if we want to support it, we have to keep updating the native menu structure in the background, not only when a menu is activated. Actually that's the only reason we need to keep listening to status updates in MenuBarManager all the time (as noted in commit 2abdcfd641883f246fe78f2fbe38499c9382c059). But the previous solution (of commit 2abdcfd641883f246fe78f2fbe38499c9382c059) to update the whole submenu at any status update, is far from ideal, and seems to create a performance hit when starting Writer. So probably it would be better to update only the changed menu item immediately at the status update - for at least the title and enabled state. I tried to do this but got lots of warnings like "GLib-GIO-CRITICAL **: g_action_group_get_action_enabled: assertion 'G_IS_ACTION_GROUP (action_group)' failed" printed to the console. I'm not entirely sure what to do with this. @Caolán: Any thoughts on this? How (if at all) should we handle this?
No wonderful ideas come to mind immediately. Its unfortunately painful to install unity under Fedora to check this out in person. Is this just one of a bunch of menu which has this problem, or an isolated example where changing what base does there would being it into line with working ones ?
(In reply to Caolán McNamara from comment #5) > Is this just one of > a bunch of menu which has this problem, or an isolated example where > changing what base does there would being it into line with working ones ? It affects all menus in all modules. If a menu item was disabled, and later enabled (e.g. by selecting some object) it will not be reflected in HUD. Or if the item title changes (e.g. the undo item), it will show the old title.
I have an idea how to solve this.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a05b67585249b895a70e7fae89dc177e3aeaf57a tdf#102266 Try to keep HUD up to date It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A little update: neither the "Page numbers" and "Date and time" commands are available through the Unity HUD in the report builder