I'm not sure if this is actually a bug, or if it really is due to xfwm4. When gtk_window_present is called for a hidden window it doesn't get focus. If it is called for a window that isn't hidden it does. I'm not sure if this is the reason, but I've noticed that when running some applications under xfwm4, some dialogs (such as search dialogs) don't get focus when they probably should.
I've looked into the code for gtk_window_present, and it's probably a bug/feature in GTK, although I'm not 100%. Here's the relevant code: if (GTK_WIDGET_VISIBLE (window)) { g_assert (widget->window != NULL); gdk_window_show (widget->window); /* note that gdk_window_focus() will also move the window to * the current desktop, for WM spec compliant window managers. */ gdk_window_focus (widget->window, gtk_get_current_event_time ()); } else { gtk_widget_show (widget); } So I think when the window isn't visible, they're relying on gtk_widget_show to give the window focus, which is probably wrong. Or maybe they don't think it should get focus for some reason. So I think I'll take this up with the GTK people, but any guidance is appreciated, since I really don't know what I'm talking about here. In case you're wondering, I assumed that this was a bug with xfwm because it works as I'd expect with other window managers that I've tried. Sorry.
A quick test doesn't exhibit the problem. Could you provide a little piece of code that could show the problem?
Here is why: xfwm4-4.1.90 had that nice 'anti focus stealing" feature activated, unfortunately GTK doesn't update its "user_time" field reliably. Since the user_time is not up to date, xfwm4 doesn't give focus (that's precisely how "anti-focus-stealing" works). In xfwm4 4.1.91, that feature has been made optional and disabled by default.
Thanks for looking into that. I do like the anti-focus stealing, so I think that for now I'll just hack any programs where this causes problems (calling gtk_window_show before present seems to work).