>>>>> "Abdel" == Abdel <[EMAIL PROTECTED]> writes:
Abdel> OK, thanks. My main problem is that while a MenuItem is of Abdel> Submenu kind, sometimes (depends on the document you load and Abdel> the time of day) its associated submenu is empty. This happens Abdel> only for the Navigate menu, others works fine. I think this is related to your next question. Menu objects are "uninstantiated" menus, and expand should be called on the one you want to open (File, Edit...) before doing anything else. I agree this is not a very good API (instantiated menus should be a different C++ class), but I do not think it is a big problem, actually. Abdel> In my opinion we should just be able to use getMenu() without Abdel> having to expand it. In this case MenuVackend member menulist_ Abdel> should of course be mutable (because getMenu is a const Abdel> function). So the MenuBackend should make sure that the menu Abdel> you ask for is always up to date. I don't like mutable variables :) The question is probably why you want to get these menus. Are you trying to use MenuBackend to build your dynamic ToC stuff? In this case I think you are using the wrong approach. You should take the horrible code from MenuBackend and merge it into toc.C. This code should return the ToC as a tree (not a list of strings) and MenuBackend and your code should use that directly. Abdel> Another problem that I have is with the MenuItem::func() Abdel> member. I store it this way in a QLAction which is a lyx Abdel> tailored QAction: QLAction * action = new Abdel> QLAction(*(owner_->view()), label, m->func()); So the Abdel> FuncRequest is stored in the QLAction and is called when you Abdel> click on the corresponding MenuItem. The problem is that this Abdel> make lyx crashing for some MenuItem randomly (not all). It Abdel> seems that this FuncRequest is not constant for a given Abdel> MenuItem... weird. I'd have to see the crash. Abdel> My idea is that in the future, maybe for 1.5, there should be a Abdel> unique configuration file which will describe all available Abdel> FuncRequests, together with associated label, icon, tooltip, Abdel> number of argument (if any), etc. All these will be converted Abdel> into QLAction. These QLAction would then be available as Abdel> MenuItem or Toolbar button indifferently. I am not sure we want that, in particular for labels. Do we really want to enforce the way the menu appears? Abdel> I realize now that my explanation is a bit abstract so I attach Abdel> my ports of QView, QLMenubar and QLPopupmenu to this mail Abdel> (QLAction is defined in QView.[hC] Abdel> Sorry Jean-Marc, you asked for it ;-) No problem. JMarc