Re: XEmacs/GTK does menus...
Hrvoje Niksic <hniksic(a)iskon.hr> writes:
wmperry(a)aventail.com (William M. Perry) writes:
> > I'm 100% sure -- I've been seeing it for a while. Because of
> > that, popups with many submenus are extremely slow as they need to
> > evaluate all the :active statements. Things get even worse when
> > filters come into play.
>
> Cool, then I did a good thing. :)
Definitely. Now, if you could do the same with popup menus, it'd be
totally cool. As well as hip and rad. Nag, nag.
Uhhhh... already done. :) The code that constructs the widgets is all
shared code. There is a 'convert_menu' function that returns a GtkMenuItem
that is suitable for inclusion into a GtkMenuBar. popup_menu just calls
this function, rips out the submenu, instantiates the first-level widgets,
and bob is your uncle. :)
> > You can always take a look at what Windows people have
done.
> > Although I'd rather you wouldn't :), because the mswindows toolbar
> > doesn't behave properly, for instance it doesn't generate motion
> > events when mouse moves over the toolbar.
>
> Well, is the only reason for motion events while over the toolbar
> for tooltips? Those are handled natively by the GTK toolbar.
Can you embed images in such tooltips?
Ick! I should hope not. :)
Do they do the right thing with Mule-coded text (hi Stephen)?
Doesn't look like it. I need to try and do a build this afternoon with
mule anyway. That should be interesting. :)
Can you press button3 to popup a context-sensitive menu (you can do
this
with correctly dispatched events)?
Hrm. Probably could.
None of these things are crucial, but are one argument against
default
system-specified tooltips.
I'll have to see how far I get. I think good integration with the native
widgets is a good reason to make the implementation a little harder.
Dealing with mule should be my burden, I shouldn't burden the user with
crappy toolbars. :)
-Bill P.