Sorry again, I miss this one too. I should maybe inscribe lyx-devel
instead of using gmane...
Abdel.
Jean-Marc Lasgouttes a écrit :
"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
