Re: x-popup-dialog in gtk emacs

[Jan D.]

Dave Love wrote:
> If you do something like this in the gtk-based Emacs, the only way to
> get out of it seems to be to select a menu, otherwise Emacs appears to
> be hung:
>
>   (x-popup-dialog t '("foo" "bar"))
>
> In the lucid version, a mouse click removes the dialogue box.

I don't know which version you are running, but in a recent CVS, the lucid
version does not pop down on a click.  Neither does the Motif version.

Motif and GTK does pop down on ESC.  And if you have some window manager,
there usualy are some "kill window" button on the title bar.

> I know this isn't a terribly useful thing to do, but I was testing.
> It's probably reasonable to refuse to pop up a dialogue with no
> selectable elements, as long as it's done consistently across ports
> and toolkits.

> By the way, the gtk menus seem rather slow compared with the lucid
> ones.  Is that a known feature?  I saw this on the box I had to use to
> build and run the gtk version to try it conveniently: a headless P200
> with X over 100Mb ethernet.  The installed Emacs 21.2 displays the
> lucid menus without noticeable delays, whereas the gtk version pauses
> displaying and removing menus.  With menu-bar-mode off using
> C-down-mouse-3 in *scratch* I estimate takes 1-2s for the popup menu
> to appear, and maybe half as long to disappear if I release the mouse
> without selecting anything.

GTK is very inefficient for Emacs dynamic menus.  Everytime one clicks on a 
menu the code traverses the menu structure to see if there are any changes.

GTK menus are containers and to get the list of widgets contained, GTK 
allocates a new list, and new nodes, and initializes the list.  Then we 
traverse the list, which in turm may also be a container.  Then these lists are 
freed.  All just to see if things are up to date.  So there are a lot of malloc 
and free going on, I guess this is what makes it slow.

        Jan D.