On Mon, Mar 25, 2002 at 10:08:01AM +0100, Jean-Marc Lasgouttes wrote:
> 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.
no, I mean each /button/ needs a name. Also we want to be able to
specify whether a toolbar should be horizontal, vertical, t,b,l,r too...
We already have NewLine, so we just need to be a bit more flexible. Qt
frontend can already make the standard toolbar vertical (but it looks a
bit silly)
> 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.
Ah, I see it. I can do that too.
> 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.
great.
> You do not have to do menu creation on demand. You are free to
> implement menus as you see fit.
This does not appear to be true, in particular for the view/update
dynamic menu, currently I must wait for a buffer before I can get my
data.
> 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.
I don't think this is a good thing. I'm not even sure it can be done
reliably in Qt, and I'd rather not try ;)
> 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?
it just confused me :) I'm dumb ...
> Feel free to propose something else. We could also decide that we do
> not need a different menu set when there is no document.
ISTR the problem is that you can't disable an entire menu in xforms,
right ?
> 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.
Of course, please don't take my comments as criticism.
I'm amazed by how well most of lyx has held up under a Qt world.
> What is the typical Qt way of handling menus like those of LyX?
I don't really know, I've never written a Qt application before ...
What I think I would like to see is something like a
MenuBackend ----> Menu_pimpl::somethingChanged(SpecialType t)
then the pimpl can do .expand(t) to get the current list of special
entries. This can be ignored by xforms (since it will do expand at each
menu open anyway) but can be used by qt (and gnome, if it makes sense)
regards
john
p.s. I have fixed scrollbar for Qt ... now I need to refix all the
xforms stuff I've broken ;)
--
"Way back at the beginning of time around 1970 the first man page was
handed down from on high. Every one since is an edited copy."
- John Hasler <[EMAIL PROTECTED]>
