>>>>> "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

Reply via email to