GNOME Bugzilla – Bug 502930
Chat windows focus oddities
Last modified: 2008-04-19 14:41:52 UTC
The focus of chat windows is apparently not too well handled. - when I click on a contact from my roster, I'd expect the window to popup and have my focus, so I can type straight away. Instead, it always appears under by browser, and not having focus, so I have to select it first. - when I click on the new message notification icon in the notification area, again I'd expect the window to appear with focus on it. It doesn't, however. I'm using Metacity 2.20.x.
I think that's a metacity bug... or feature... When a chat is opened I call gtk_window_present(), the doc says: "Presents a window to the user. This may mean raising the window in the stacking order, deiconifying it, moving it to the current desktop, and/or giving it the keyboard focus, possibly dependent on the user's platform, window manager, and preferences."
Here is why metacity don't raise window: http://blogs.gnome.org/metacity/2007/12/24/stacking/ Chat window are not in the same process than the main window so metacity decides to not raise the window unless there is user activity on the window... How can I "generate" user activity on the chat window to be sure metacity raises it? I already use gtk_window_present_with_time (chat_window, gtk_get_current_event_time ()); But since we are in a different process and not in the one we had the click event I guess that returns a timestamp==0 and that makes metacity ignore the raise request. How can I work arround that?
It seems to me that the idea of raising a window because of an action in another window, when the windows are as closely related as these are, is exactly why there is the exemption for members of the same ICCCM group. Are these two windows *not* members of the same group? If not, why not?
What re ICCCM groups and how can I define them to be sure both programs are in the same group ?
Just wondering, does putting them together in the same ICCCM group also help against the case when the rooster is closed? (No, right?)
They are not in the same ICCCM group because the window_group is the X window id of a window in the group but the two programs don't know of the existence of the other one, so they cannot set the window_group to a useful value. It would be far easier if the window_group was a string or something similar.
Chats are now in the same process, so this bug is fixed. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.