After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 502930 - Chat windows focus oddities
Chat windows focus oddities
Status: RESOLVED FIXED
Product: empathy
Classification: Core
Component: General
0.21.x
Other Linux
: Normal normal
: ---
Assigned To: empathy-maint
empathy-maint
Depends on:
Blocks:
 
 
Reported: 2007-12-10 21:34 UTC by Jordi Mallach
Modified: 2008-04-19 14:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jordi Mallach 2007-12-10 21:34:28 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.
Comment 1 Xavier Claessens 2007-12-20 13:11:57 UTC
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."
Comment 2 Xavier Claessens 2007-12-24 08:54:32 UTC
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?
Comment 3 Thomas Thurman 2007-12-24 12:48:49 UTC
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?
Comment 4 Xavier Claessens 2007-12-27 11:20:49 UTC
What re ICCCM groups and how can I define them to be sure both programs are in the same group ?
Comment 5 Martin Ejdestig 2008-01-06 05:05:03 UTC
Just wondering, does putting them together in the same ICCCM group also help against the case when the rooster is closed? (No, right?)
Comment 6 Marco Barisione 2008-02-18 14:38:18 UTC
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.
Comment 7 Xavier Claessens 2008-04-19 14:41:52 UTC
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.