Re: New Menu::expand method in menu backend
On Fri, 13 Oct 2000, Dekel Tsur wrote: On Mon, Oct 09, 2000 at 04:23:39PM +0200, Jean-Marc Lasgouttes wrote: To put it another way, I thought I could just add a Menu* member in menuitem and that Menu::expand would just populate that for items of type Submenu for Toc and Ref. I have a few questions, though: I think that my suggestion is a little bit cleaner. - for the refs menu, it seems to me that the special entry should just provide a list of references (as submenus), not the whole refs menu with four times the same information. It has been claimed that the Refs menu is redundant, and I think that I agree. The whole purpose of this menu was a fast way for adding references, but using the new reference dialog (with the keyboard) is as fast as using the Refs menu. True, you can add/edit the reference quite fast with the dialog. - why not modify the refs menu to something similar to (o) Insert Reference ( ) Insert page reference ( ) Insert pretty ref ( ) Goto ref [...] - label1...label10 label11...label21 It seems to me that this would be less confusing than having five submenus with the same contents (and you have one less click when using often the same function). With this view of things, only the part under the separator would be a special entry. The rest could be handled via normal stuff. Does it mean that if you want to insert "page reference" after plain reference you will have to navigate through the menus, select "Insert page reference" and since the menu will close, you will have to navigate once more and then select the reference. The same holds for just "Goto ref". It seems to me that it is not expected that you have to go to the menu twice for an action. For me it is much more confusing than to navigate through menus by selecting what I want to do with the reference and then selecting particular reference (as it is now) :). Marko
Re: New Menu::expand method in menu backend
"Marko" == Marko Vendelin [EMAIL PROTECTED] writes: It has been claimed that the Refs menu is redundant, and I think that I agree. The whole purpose of this menu was a fast way for adding references, but using the new reference dialog (with the keyboard) is as fast as using the Refs menu. Marko True, you can add/edit the reference quite fast with the Marko dialog. So should it be removed? It adds quite a bit of complexity to the menu code... Marko Does it mean that if you want to insert "page reference" after Marko plain reference you will have to navigate through the menus, Marko select "Insert page reference" and since the menu will close, Marko you will have to navigate once more and then select the Marko reference. The same holds for just "Goto ref". It seems to me Marko that it is not expected that you have to go to the menu twice Marko for an action. For me it is much more confusing than to Marko navigate through menus by selecting what I want to do with the Marko reference and then selecting particular reference (as it is Marko now) :). OK, OK, it was just a proposal :) JMarc
Re: New Menu::expand method in menu backend
On 13 Oct 2000, Jean-Marc Lasgouttes wrote: Marko True, you can add/edit the reference quite fast with the Marko dialog. So should it be removed? It adds quite a bit of complexity to the menu code... I would be happy with it: we can then declare Menubar in guii.php3 as "Completed". However, maybe it is better to ask lyx-users@... first? I don't know what are the procedures of removing the features in LyX... Marko
Re: New Menu::expand method in menu backend
"Marko" == Marko Vendelin [EMAIL PROTECTED] writes: Marko On 13 Oct 2000, Jean-Marc Lasgouttes wrote: True, you can Marko add/edit the reference quite fast with the dialog. So should it be removed? It adds quite a bit of complexity to the menu code... Marko I would be happy with it: we can then declare Menubar in Marko guii.php3 as "Completed". However, maybe it is better to ask Marko lyx-users@... first? I don't know what are the procedures of Marko removing the features in LyX... I guess the best procedure is to #ifdef it out, tell people to use the popup intead, and if they _really_ complain, re-introduce it :) JMarc
Re: New Menu::expand method in menu backend
On Fri, 13 Oct 2000, Dekel Tsur wrote: > On Mon, Oct 09, 2000 at 04:23:39PM +0200, Jean-Marc Lasgouttes wrote: > > > > To put it another way, I thought I could just add a Menu* member in > > menuitem and that Menu::expand would just populate that for items of > > type Submenu for Toc and Ref. I have a few questions, though: > > I think that my suggestion is a little bit cleaner. > > > - for the refs menu, it seems to me that the special entry should just > > provide a list of references (as submenus), not the whole refs menu > > with four times the same information. > > It has been claimed that the Refs menu is redundant, and I think that I agree. > The whole purpose of this menu was a fast way for adding references, but > using the new reference dialog (with the keyboard) is as fast as using the > Refs menu. True, you can add/edit the reference quite fast with the dialog. > > - why not modify the refs menu to something similar to > > > > (o) Insert Reference > > ( ) Insert page reference > > ( ) Insert pretty ref > > ( ) Goto ref > > [...] > > - > > label1...label10 >> > > label11...label21 >> > > > > It seems to me that this would be less confusing than having five > > submenus with the same contents (and you have one less click when > > using often the same function). With this view of things, only the > > part under the separator would be a special entry. The rest could be > > handled via normal stuff. Does it mean that if you want to insert "page reference" after plain reference you will have to navigate through the menus, select "Insert page reference" and since the menu will close, you will have to navigate once more and then select the reference. The same holds for just "Goto ref". It seems to me that it is not expected that you have to go to the menu twice for an action. For me it is much more confusing than to navigate through menus by selecting what I want to do with the reference and then selecting particular reference (as it is now) :). Marko
Re: New Menu::expand method in menu backend
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: >> It has been claimed that the Refs menu is redundant, and I think >> that I agree. The whole purpose of this menu was a fast way for >> adding references, but using the new reference dialog (with the >> keyboard) is as fast as using the Refs menu. Marko> True, you can add/edit the reference quite fast with the Marko> dialog. So should it be removed? It adds quite a bit of complexity to the menu code... Marko> Does it mean that if you want to insert "page reference" after Marko> plain reference you will have to navigate through the menus, Marko> select "Insert page reference" and since the menu will close, Marko> you will have to navigate once more and then select the Marko> reference. The same holds for just "Goto ref". It seems to me Marko> that it is not expected that you have to go to the menu twice Marko> for an action. For me it is much more confusing than to Marko> navigate through menus by selecting what I want to do with the Marko> reference and then selecting particular reference (as it is Marko> now) :). OK, OK, it was just a proposal :) JMarc
Re: New Menu::expand method in menu backend
On 13 Oct 2000, Jean-Marc Lasgouttes wrote: > Marko> True, you can add/edit the reference quite fast with the > Marko> dialog. > > So should it be removed? It adds quite a bit of complexity to the menu > code... I would be happy with it: we can then declare Menubar in guii.php3 as "Completed". However, maybe it is better to ask lyx-users@... first? I don't know what are the procedures of removing the features in LyX... Marko
Re: New Menu::expand method in menu backend
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> On 13 Oct 2000, Jean-Marc Lasgouttes wrote: True, you can Marko> add/edit the reference quite fast with the dialog. >> So should it be removed? It adds quite a bit of complexity to the >> menu code... Marko> I would be happy with it: we can then declare Menubar in Marko> guii.php3 as "Completed". However, maybe it is better to ask Marko> lyx-users@... first? I don't know what are the procedures of Marko> removing the features in LyX... I guess the best procedure is to #ifdef it out, tell people to use the popup intead, and if they _really_ complain, re-introduce it :) JMarc
Re: New Menu::expand method in menu backend
On Mon, Oct 09, 2000 at 04:23:39PM +0200, Jean-Marc Lasgouttes wrote: To put it another way, I thought I could just add a Menu* member in menuitem and that Menu::expand would just populate that for items of type Submenu for Toc and Ref. I have a few questions, though: I think that my suggestion is a little bit cleaner. - for the refs menu, it seems to me that the special entry should just provide a list of references (as submenus), not the whole refs menu with four times the same information. It has been claimed that the Refs menu is redundant, and I think that I agree. The whole purpose of this menu was a fast way for adding references, but using the new reference dialog (with the keyboard) is as fast as using the Refs menu. - why not modify the refs menu to something similar to (o) Insert Reference ( ) Insert page reference ( ) Insert pretty ref ( ) Goto ref [...] - label1...label10 label11...label21 It seems to me that this would be less confusing than having five submenus with the same contents (and you have one less click when using often the same function). With this view of things, only the part under the separator would be a special entry. The rest could be handled via normal stuff. How this would be implemented? (Does it requires adding new lyxfunc ?)
Re: New Menu::expand method in menu backend
On Mon, Oct 09, 2000 at 04:23:39PM +0200, Jean-Marc Lasgouttes wrote: > > To put it another way, I thought I could just add a Menu* member in > menuitem and that Menu::expand would just populate that for items of > type Submenu for Toc and Ref. I have a few questions, though: I think that my suggestion is a little bit cleaner. > - for the refs menu, it seems to me that the special entry should just > provide a list of references (as submenus), not the whole refs menu > with four times the same information. It has been claimed that the Refs menu is redundant, and I think that I agree. The whole purpose of this menu was a fast way for adding references, but using the new reference dialog (with the keyboard) is as fast as using the Refs menu. > - why not modify the refs menu to something similar to > > (o) Insert Reference > ( ) Insert page reference > ( ) Insert pretty ref > ( ) Goto ref > [...] > - > label1...label10 >> > label11...label21 >> > > It seems to me that this would be less confusing than having five > submenus with the same contents (and you have one less click when > using often the same function). With this view of things, only the > part under the separator would be a special entry. The rest could be > handled via normal stuff. How this would be implemented? (Does it requires adding new lyxfunc ?)
Re: New Menu::expand method in menu backend
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel After reading the ui file, we have a representation of the menu Dekel by a rooted tree, whose nodes are instances of the Menu class Dekel (if I read the code correctly, the edges of the tree are stored Dekel using the submenu_ strings, and not with pointers). The expand Dekel function (it can be implemented as a method, but lets assume it Dekel is a function) receives some node in this tree (the root in the Dekel case of gnome/kde, or a child of the root in the case of Dekel xforms) and does the following: It traverses the node and its Dekel descendents, and creates a copy of the scanned subtree, but in Dekel the copy tree, the "special" items are expanded. When expanding Dekel the TOC, new nodes may be added to the copy tree. The copy tree Dekel is then passed to the frontend code, so the frontend code just Dekel need to traverse the tree it receives, and process it. To put it another way, I thought I could just add a Menu* member in menuitem and that Menu::expand would just populate that for items of type Submenu for Toc and Ref. I have a few questions, though: - if there is a need for an "update" menu entry for gnome, expand() should be aware of that somehow. Another solution would be that expand() leaves the entries it has expanded in place, and that the frontend would be free to either ignore them or take special action. - for the refs menu, it seems to me that the special entry should just provide a list of references (as submenus), not the whole refs menu with four times the same information. - why not modify the refs menu to something similar to (o) Insert Reference ( ) Insert page reference ( ) Insert pretty ref ( ) Goto ref [...] - label1...label10 label11...label21 It seems to me that this would be less confusing than having five submenus with the same contents (and you have one less click when using often the same function). With this view of things, only the part under the separator would be a special entry. The rest could be handled via normal stuff. Dekel, comments? JMarc
Re: New Menu::expand method in menu backend
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> After reading the ui file, we have a representation of the menu Dekel> by a rooted tree, whose nodes are instances of the Menu class Dekel> (if I read the code correctly, the edges of the tree are stored Dekel> using the submenu_ strings, and not with pointers). The expand Dekel> function (it can be implemented as a method, but lets assume it Dekel> is a function) receives some node in this tree (the root in the Dekel> case of gnome/kde, or a child of the root in the case of Dekel> xforms) and does the following: It traverses the node and its Dekel> descendents, and creates a copy of the scanned subtree, but in Dekel> the copy tree, the "special" items are expanded. When expanding Dekel> the TOC, new nodes may be added to the copy tree. The copy tree Dekel> is then passed to the frontend code, so the frontend code just Dekel> need to traverse the tree it receives, and process it. To put it another way, I thought I could just add a Menu* member in menuitem and that Menu::expand would just populate that for items of type Submenu for Toc and Ref. I have a few questions, though: - if there is a need for an "update" menu entry for gnome, expand() should be aware of that somehow. Another solution would be that expand() leaves the entries it has expanded in place, and that the frontend would be free to either ignore them or take special action. - for the refs menu, it seems to me that the special entry should just provide a list of references (as submenus), not the whole refs menu with four times the same information. - why not modify the refs menu to something similar to (o) Insert Reference ( ) Insert page reference ( ) Insert pretty ref ( ) Goto ref [...] - label1...label10 >> label11...label21 >> It seems to me that this would be less confusing than having five submenus with the same contents (and you have one less click when using often the same function). With this view of things, only the part under the separator would be a special entry. The rest could be handled via normal stuff. Dekel, comments? JMarc
Re: New Menu::expand method in menu backend
On Wed, Oct 04, 2000 at 11:53:53AM +0200, Jean-Marc Lasgouttes wrote: I do not know how this code could be adapted to the case of Toc and Ref entries, since they contain submenus. Ideas are welcome, of course. The follownig scheme can be used: After reading the ui file, we have a representation of the menu by a rooted tree, whose nodes are instances of the Menu class (if I read the code correctly, the edges of the tree are stored using the submenu_ strings, and not with pointers). The expand function (it can be implemented as a method, but lets assume it is a function) receives some node in this tree (the root in the case of gnome/kde, or a child of the root in the case of xforms) and does the following: It traverses the node and its descendents, and creates a copy of the scanned subtree, but in the copy tree, the "special" items are expanded. When expanding the TOC, new nodes may be added to the copy tree. The copy tree is then passed to the frontend code, so the frontend code just need to traverse the tree it receives, and process it.
Re: New Menu::expand method in menu backend
On Wed, Oct 04, 2000 at 11:53:53AM +0200, Jean-Marc Lasgouttes wrote: > > I do not know how this code could be adapted to the case of Toc and > Ref entries, since they contain submenus. Ideas are welcome, of > course. The follownig scheme can be used: After reading the ui file, we have a representation of the menu by a rooted tree, whose nodes are instances of the Menu class (if I read the code correctly, the edges of the tree are stored using the submenu_ strings, and not with pointers). The expand function (it can be implemented as a method, but lets assume it is a function) receives some node in this tree (the root in the case of gnome/kde, or a child of the root in the case of xforms) and does the following: It traverses the node and its descendents, and creates a copy of the scanned subtree, but in the copy tree, the "special" items are expanded. When expanding the TOC, new nodes may be added to the copy tree. The copy tree is then passed to the frontend code, so the frontend code just need to traverse the tree it receives, and process it.
