GTK+ Forums

Seasons Greetings, fellow GTKers.

I have this experimental little app that is supposed to pop up a menu on SIGUSR1. It's pretty much right out of the tutorial:

It works properly when first called. The silly little menu pops up under the mouse. Click an entry or hit ESCAPE and it goes away. Perfect.

I send a SIGUSR1 to the app, it catches it, prints a little confirmation that it did indeed catch it, then calls gtk_widget_show_all(menu1) and gtk_menu_popup(menu1, ...), and nothing. The menu doesn't reappear. First I thought the widgets were being destroyed, but then I'd surely get a segfault or CRITICAL on the gtk_widget_show_all().

As an addendum, if I don't call gtk_menu_popup() in this function, then SIGUSR1 works the first time, but never again. Why does gtk_menu_popup() only work once and then fail silently?

I've been digging through the gtk c code looking for clues, and of course I've googled many many pages thinking some else must have tried to do this very same thing, but to no avail.

Any notion why this would be?

Hello and welcome,

It confused me at first until I saw that you are using SIGUSR1.

I expect that you are calling all your GTK+ code to do the pop-up menu from the UNIX signal handler. If so then this is what has caused your problem. There are very few functions that you can call from within a UNIX signal handler have a look at the man page for it signal(7)


What has happened is -
1 - First time the UNIX signal handler is called GTK+ is interrupted mid flow, the pop-up menu is generated and some of the internal structures used by GTK+ are now corrupted.
2 - Second time the UNIX signal handler is called GTK+ is again interrupted mid flow. Because the required internal data structures are now corrupt the menu can not be now shown.

Best would be to avoid the use of UNIX signals. If you can not have you GTK+ main loop monitor a pipe for data coming in. Whenever the expected data comes in using the GTK+ handler to display your pop-up menu. In your UNIX signal handler have it send data on the pipe (this should be OK to do).

_________________
E.

That totally makes sense. Thank you. I hadn't thought about the interaction of signals rudely interrupting the main loop.

The funny thing is that this trick completely works if I make gtk_window, populate it with widgets (buttons and stuff), and widget_show() everything but the window. When the SIGUSR1 comes through, it just calls widget_show() on the top level window which has GTK_WIN_POS_MOUSE set. Bang. It pops up at the mouse. Lovely. Grab some signals and ESC/F10, button-press or leave-notify makes it disappear.

Menus behave differently. A lot of their function is controlled internally, unlike a button which is mostly user-controlled. With a menu, gtk_widget_show() isn't good enough, you must call menu_popup() which then pretty much takes over control.

For now, as an experiment, I skip the SIGUSR1 bit and use a different approach. In my gtk_window/button version of this app, I have also installed a g_timeout_add() that lazily polls the pointer every 10th of a second:

and

window_show() is designed as a signal callback, and just sets a couple flags then calls gtk_widget_show_all() or gtk_menu_popup(), whichever is appropriate.

What is supposed to happen here is that when you right click an empty spot of the root window, my button window pops up under the mouse. No problem. Not so when it's a menu.

Now, if you'll notice, I've hacked this routine to count, and every 100(~10 seconds) it shows the menu. Strangely this works perfectly. Every 10 seconds gtk_menu_popup() does it's thing, and my gtk_menu pops up under your mouse. Awesome. But when I right click, it still calls menu_popup() but fails.

What I've discovered is that menu_popup() succeeds when it's called passively from the app, but but fails when called actively from UNIX signals or mouse clicks. It seems that all the gtk_menu's automagic gets confused by the spurious events going on.

This ties right into all the chat I've seen about gtk-menu-popup-delay and getting it set just right. I was curious if this might help. Perhaps giving a small delay to the popup would lets things clear. So I tried a trick someone said. echo "gtk-menu-popup-delay = 10000" >> ~/.gtkrc-2.0. But that doesn't seem to do anything. I tried usleep(100000) right before calling gtk_menu_popup(), and you know what? *IT WORKS*! But only for right-click. Still not for SIGUSR1.

So, I decided to try another trick. In my signal handler, instead of just abruptly calling window_show(), I did this:

The main loop keeps right on rolling, and a moment later there is a friendly knock on the door to menu_popup(), and you know what? It now works for SIGUSR1 also.

So, after MUCH experimentation, I believe I found the official answer to my original query:

gtk_menu and friends get confused by spurious events, so if you're going to be calling gtk_menu_popup(), do it with a leisurely g_timeout_add() and a GSourceFunc that returns FALSE, so it only calls once. The correct timer delays seem to be 200 for SIGUSR1 and 100 for right click.

Perhaps someone else can benefit from this little tidbit of gtk esoterica.

Have a very Merry Christmas.