>>>>> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> also, I need a name for each icon that can be shown in qt when John> the toolbar is too wide... oh, and some moving around of John> setPixmap to be GUII (I'll do that soon in my guii tree) Yes, the plan was to have names for the toolbars. This allows for having a "math" or "tabular" toolbar which appears when the core requests it. John> As for menubar, it needs a /total/ overhaul I think. It /might/ John> be possible to get the current version working with Qt, but it's John> a real struggle. Here's a few of the things I want : John> 1. shortcuts available (how does xforms do this ? haven't looked John> ...) xforms queries the binding from toplevel_keymap. The way it is displayed in the menu is by using Tabs. For Qt, you may have to use a different trick. John> 2. open_by_name makes little sense for Qt, it can handle it John> already (probably qt can just continue to ignore this) The only place where this is used is the binding lib/bind/emacs.bind:\bind "C-x C-b" "menu-open documents" I think we can get rid of it, especially since it will not work with non-english interface. John> 3. the on-demand menu creation. This is a real pain for Qt. John> Rather I would like expand() to work at Menubar_pimpl John> constructor (I already have this, sort of), and provide some John> signals to connect to so we can know whether to update the John> "special" menus You do not have to do menu creation on demand. You are free to implement menus as you see fit. The only constraint is that you have to make sure before a menu is open that all items are disabled/toggled, etc. as needed. So anyway, you have to do _some_ work before showing a menu. Also, you can probably ignore the table of contents stuff for now, since we will have to fold it into menubackend in some way. My idea currently would be to provide an iterator on menu structure which would do the unfolding as needed. John> 4. probably a lot of other things. I found the way you have to John> parse the menu structure was a bit confusing ... What do you mean? John> I don't know if the main main_nobuffer technique is really best. Feel free to propose something else. We could also decide that we do not need a different menu set when there is no document. John> The menu stuff and the scrollbar are the only things really John> remaining to do for the Qt thing to happen nicely I think. It has always been clear to me that this stuff will need cleanups to be usable to the other toolkits. However, it was difficult to guess those cleanups without knowing how those toolkits operate. What is the typical Qt way of handling menus like those of LyX? JMarc
