>>>>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I think this is not possible because menu-items and Abdelrazak> tool-bar buttons use completely separated back-ends. Now I Abdelrazak> see that there is another dynamic menu-item. Is there a Abdelrazak> list of these somewhere? UI wise, IMHO, menu-item like Abdelrazak> this one should not appear and disappear, they should be Abdelrazak> grayed out. Just take a look at lib/ui/stdmenus.ui. Things that can disappear are OptItem and OptSubmenu. We are aware that this is not very nice UI-wise, but if we did not do that the Edit menu would be huge. Abdelrazak> This is an interesting fix: Why do we need this but not Abdelrazak> that: bv-> owner()->updateMenubar(); Because the fix is wrong :) The place where the update happens is here: void LyXFunc::sendDispatchMessage(string const & msg, FuncRequest const & cmd) { /* When an action did not originate from the UI/kbd, it makes * sense to avoid updating the GUI. It turns out that this * fixes bug 1941, for reasons that are described here: * http://bugzilla.lyx.org/show_bug.cgi?id=1941#c4 */ if (cmd.origin != FuncRequest::INTERNAL) { owner->updateMenubar(); owner->updateToolbars(); } Abdelrazak> IMHO, this is a good case in favor of "Lyx Action Abdelrazak> Unification" ;-) While this is not a good example, I do think that unification of menubar and toolbar would be useful. But of course, I would do it in the existing backend framework... JMarc