GNOME Bugzilla – Bug 585914
Notification icon must be clicked before user can see new messages
Last modified: 2013-03-12 21:03:56 UTC
What happens New messages show up in the notification area, and users have to click on the new message icon to see the new message. This differs from every other IM application that I have used before -- Adium, Pidgin, stock AIM client from AOL, etc. Also, I don't often look at the notification area icon, so IMs often remain unresponded to. Expected behavior Expected behavior is that messages show up in a window (or a tab, if the chat window is already open), and users do not have to click an icon to see messages -- users can switch to the window via the window list or other window manager functions. At the very least, I would appreciate a preference option to have IMs show up in the way that I described, instead of using the notification area icon.
We don't popup a window in the face of the user to not steal focus. I'm closing this bug WONTFIX because this is the desired behaviour and I dont think that needs to be changed.
You could just make it so that the window doesn't steal focus, and instead set the window manager urgent hint. This is highly *annoying* behavior, far more annoying than stealing focus, since I may be chatting in the chat window (with focus!) and not have any idea that i have received new messages if i do not look in the notification area. Again, no other IM application in existence that I know of has this behavior by default. Besides which, users can configure their own focus prevention through their window manager -- if your application steals focus, maybe that is a flaw in the window manager, for not providing an option to alert the user without stealing focus -- of course, the URGENT hint exists, so this is not the case.
"We don't popup a window in the face of the user to not steal focus." Instead, could the window be spawned in the background? With an URGENT hint, as Asif suggests. That way it wouldn't steal the focus, so I guess there would be no problem? Please think about it. I know less skilled users (my mother as an example) who would have a difficult time if this is the final behaviour. A notification icon is much more difficult to spot than a window for them.
Yup, this is something I'd like to see as well. Even if it's just an option somewhere in the Preference to have Empathy pop-up a window on new IMs.
Ok, let's reopen this bug, maybe we can add an option for that. In general I think empathy's status icon usage needs love...
Default behaviour *must* be without popups. It is actually one whole thing what makes Empathy useful for me. It could be an option, but I really don't see reason why.
Please, nobody is asking for popups. We're asking for popunders which span in the background and do NOT interrupt your workflow. Why on Earth would that detract from Empathy's usefulness to you?
*** Bug 586407 has been marked as a duplicate of this bug. ***
i think idgin's behaviour is very much acceptable. if a chat window is open then open a new tab for new conversation but the focus remains on the current tab itself.
Instead of a pop-under, also a minimised popup with alert hints can be considered. This will make it flash in the window list in the panel, but will not reveal contents to anybody (just in case a friend writes you "hey did you already talk to that idiot of your boss" while the boss is looking at your empty desktop). Skype does that I believe by default, and the same solution is currently adopted by ubuntu's update-manager to notify of updates.
I think if a chat window is already open and someone sends you a message it should simply go in a new tab that does not steal focus but the user will be aware that the chat is there. The notification icon is simply too small and too easy to forget about. New windows should be set to urgent and minimized. This seems like the best idea right now.
I wholeheartedly agree that it drives me mad having to click into the notification bar everytime some pings me. Focus stealing is not a problem of applications, but of window managers, and nowaday's WMs (compiz and metacity) get this quite right. (In fact, compiz gets it too right sometimes and puts windows in the background even if I'm not typing something).
Is anything happening with this? I got an email from a friend recently complaining I haven't been answering his IMs. "What IMs?" I said. Then I looked and saw them in history. No indication that they were ever received. Switching back to Pidgin now...
I back Noble's question because I too suffer from thus bug. This is an old bug with several users verifying it, yet it still appears to be "UNCONFIRMED". Users without a visible Notification Area simply will NOT get messages. For the default IM client in Gnome, this is unacceptable. Also, according to this document: http://library.gnome.org/devel/hig-book/stable/desktop-notification-area.html.en "Do not rely on blinking or animation as a means of alerting the user to any particular event." I heard rumors that Pidgin was replaced by Empathy as the default IM client in Ubuntu partly because the developers didn't listen to what the users wanted. To me, this issue is a no-brainer. I eagerly await resolution to this issue, as I think that Empathy is getting heavy criticism for small issues like these.
Mzmcgrat: if you had opened preferences of 2.28 version of Empathy, then you would see that there is now option to open new dialog if someone writes you first time, IMHO eliminating this bug at once. Also, in Ubuntu they now are using Indicator system plus notification system to bring info to user. Therefore when someone sends you a file or writes, envelope in up right corner turns black. It also is used to indicate new email or twitter coming up for you. In result it is very convenient. So, in a way, one part of the wish of user who reported this bug is granted: "At the very least, I would appreciate a preference option to have IMs show up in the way that I described, instead of using the notification area icon." It is now available. It won't be turned by default by GNOME release, but I think every distro/users can make their own judgments. So I suggest to close this bug as WONTFIX or FIXED (if we asume second part about not having option to turn it "new window" behaviour as main problem of the bug). Cheers everyone and keep using/making free software.
Peteris, I must admit that I am using the version of Empathy distributed with Ubuntu Karmic, version 2.28.1.1, which is not the version described in the original bug report. Maybe I'm just not seeing the option you mention in the preferences menu, but if the option to fix this issue is indeed there, I can at least pass this information along to others. I see these tabs on the preferences dialog window: General, Notifications, Sounds, Spell Checking, and Themes. The only options that seem remotely possible for popping up new windows for messages are "Open new chats in separate windows" under the "General" tab, and maybe one of the options under the "Notifications" tab. Unless the Ubuntu version is different from the default Gnome version, none of these options seem to specifically address the issue described in the bug report. If one of these options is the one you're talking about, then they are poorly labeled, and there should be a new bug report. The fact that this behavior is not the DEFAULT is perhaps a new bug report as well. Indeed, cheers to Empathy and its developers.
Mzmcgrat, sorry, it seems that I was wrong, I mistook what feature is thought for. Seems this bug is still valid. I will try to ask Empathy developers what they think about this.
Created attachment 147808 [details] [review] Adds new option to open a new chat window upon recieving a message.
This issue has bugged me too, but it took me a week or so to figure out a fix. The above patch adds an option to preferences->general->behavior to open a new chat window or tab when a user without a current chat window sends you a message. The option is currently defaulted to false/disabled. In my tests, the created window did not steal focus, but popped-under my current window and highlighted itself in the window list.
Created attachment 147904 [details] [review] Adds option to open a new chat window upon recieving a message.-Fixed Same as the patch above, with one quick fix to the formatting of the .ui file.
It looks like https://bugzilla.gnome.org/show_bug.cgi?id=548754 is a duplicate of this bug.
*** Bug 548754 has been marked as a duplicate of this bug. ***
As this seems to be a very popular request, let's confirm and fix this bug.
Review of attachment 147904 [details] [review]: Hi Ryan. Thanks a lot for your patch. I tried it and it looks pretty good to me. I inlined some style comments. When the new chat is added as a tab to an existing window, I think we shouldn't focus this tab automatically to avoid this kind of awkward situation : - You are chatting with a friend a start typing "Wow this guys is really a" - At this point your boss sends you a message but you don't notice it and continue to type - "asshole" [enter] - You just insulted your boss and lost your job :) ::: src/empathy-event-manager.c @@ +381,3 @@ + empathy_conf_get_bool (empathy_conf_get (), + EMPATHY_PREFS_UI_AUTO_OPEN_CHAT, + &auto_open_chat); These params should be aligned using 4 spaces. @@ +383,3 @@ + &auto_open_chat); + + if(auto_open_chat) Our coding style is "if (condition)". You can use "make check" to check if you didn't introduce coding style regressions.
Hummm, seems this problem also happen when opening a new popup. I just tried and it does steal my focus. You should popunder the new chat.
It would be nice to have an option to automatically open new messages if there is a chat window open already, without spawning a new one.
(In reply to comment #25) > Hummm, seems this problem also happen when opening a new popup. I just tried > and it does steal my focus. You should popunder the new chat. This seems to be because of a problem in existing code, I will investigate.
I'm not sure that pop behind all the time is necessarily the best behavior, and personally quite like the patch's behavior (for the most part; some suggestions below). Popping up behind and sending the WM an URGENT hint isn't much of an improvement over the notification icon flashing, apart from the fact it's slightly more noticeable. There are a few use cases which this solution does not address at all: 1) Users with numerous open windows on a particular workspace. In this case the window pager will shrink each window button down to a small size, effectively making it as useful as having a notification icon. 2) Users running netbook-optimised systems, eg Ubuntu Netbook Remix. In this case, the window pager reduces each window button (except the active window) to the size of its icon with NO text at all. Basically case 1 in the extreme. Note that I have no idea how Moblin acts, so I can't vouch as to whether this solution is a good or bad one in that specific case. 3) Users without a window pager (eg I run GNOME Do using the Docky interface and have pretty much removed any panels from my desktop). 4) What about disabled users? Does the WM notify them that a new window has been opened behind the currently active window? 5) Should this be a WM preference anyway so that automatically opening windows do not steal focus? 6) This solution still goes against the GNOME HIG (as brought up in comment 14): "Do not rely on blinking or animation as a means of alerting the user to any particular event." My suggestion: except when set to Busy, open a new conversation window and bring it to the top if there are no existing conversation windows open with that person. Otherwise, just append the message to the existing window and provide a regular notification (libnotify, flashing, etc). Of course, we still keep in mind that if the person already has an Empathy window focused, don't change tabs or anything (the existing patch needs to be modified). The reason I don't think bringing the chat window to the top is such a bad idea because: 1) even if you are typing, you're not going to go hit enter after typing something, and you're going to notice that the focus has changed (it's certainly not subtle like a tab change, for example). 2) if you're Busy, it's not going to come up and be a distraction. Otherwise, you're probably willing to talk if a conversation comes up (eg a phone call comes up, you probably want to answer it if you're not doing anything). 3) most other IM clients already use this behavior (see previous comments). This has confused and annoyed some people I know who are new to Linux, and drove me nuts. I also moved back to Pidgin, but after applying this patch things are much nicer. :) I wouldn't mind having the ability to pick and choose, but that's kinda providing the user with too many small (and possibly confusing) options - and most GNOME apps try to avoid against this (as you guys probably know). Perhaps offer the ability to go always pop under as a GConf setting? This would also enable distros to pick and choose which behavior they want if they do some user testing and disagree with my opinion. ;)
Yeah, I agree. There are some users, including me, that have the panel auto-hide, so I wont see any flashing icon at all. I also have awn mainly as my window list, and have it auto-hide when a window is covering it so I wouldn't see a pop-under window until I make awn unhide by hovering over it with the the mouse instead of alt-tabbing like usual.
Created attachment 148358 [details] [review] Open new chat window on new message (modification of previous) Few changes to the previous patch: * make sure we don't introduce coding style regressions. * only bring up the popup window if we're not busy * don't change the focus state of the tab upon receiving a new message if Empathy is already focused (as per Guillaume's suggestion)
Comment on attachment 148358 [details] [review] Open new chat window on new message (modification of previous) >From c91b12e0df2c79cc88413cfe8e4ea93d51fc161e Mon Sep 17 00:00:00 2001 >From: Alex Hixon <alex@alexhixon.com> >Date: Tue, 24 Nov 2009 11:54:56 +1100 >Subject: [PATCH] Add option to automatically open new chat window/tab (#585914). > >Based on patch by Ryan LaBelle <traxdagamer@gmail.com>. >--- > libempathy-gtk/empathy-conf.h | 1 + > src/empathy-chat-window.c | 11 +++++++---- > src/empathy-event-manager.c | 26 ++++++++++++++++++++------ > src/empathy-preferences.c | 6 ++++++ > src/empathy-preferences.ui | 15 +++++++++++++++ > 5 files changed, 49 insertions(+), 10 deletions(-) > >diff --git a/libempathy-gtk/empathy-conf.h b/libempathy-gtk/empathy-conf.h >index d8e34f6..dea4827 100644 >--- a/libempathy-gtk/empathy-conf.h >+++ b/libempathy-gtk/empathy-conf.h >@@ -70,6 +70,7 @@ struct _EmpathyConfClass { > #define EMPATHY_PREFS_CHAT_AVATAR_IN_ICON EMPATHY_PREFS_PATH "/conversation/avatar_in_icon" > #define EMPATHY_PREFS_CHAT_WEBKIT_DEVELOPER_TOOLS EMPATHY_PREFS_PATH "/conversation/enable_webkit_developer_tools" > #define EMPATHY_PREFS_UI_SEPARATE_CHAT_WINDOWS EMPATHY_PREFS_PATH "/ui/separate_chat_windows" >+#define EMPATHY_PREFS_UI_AUTO_OPEN_CHAT EMPATHY_PREFS_PATH "/ui/auto_open_chat" > #define EMPATHY_PREFS_UI_MAIN_WINDOW_HIDDEN EMPATHY_PREFS_PATH "/ui/main_window_hidden" > #define EMPATHY_PREFS_UI_AVATAR_DIRECTORY EMPATHY_PREFS_PATH "/ui/avatar_directory" > #define EMPATHY_PREFS_UI_SHOW_AVATARS EMPATHY_PREFS_PATH "/ui/show_avatars" >diff --git a/src/empathy-chat-window.c b/src/empathy-chat-window.c >index 278c8f0..9c0d6bd 100644 >--- a/src/empathy-chat-window.c >+++ b/src/empathy-chat-window.c >@@ -1891,10 +1891,13 @@ empathy_chat_window_present_chat (EmpathyChat *chat) > empathy_chat_window_add_chat (window, chat); > } > >- priv = GET_PRIV (window); >- empathy_chat_window_switch_to_chat (window, chat); >- empathy_window_present (GTK_WINDOW (priv->dialog), TRUE); >+ /* If the window is already focused, don't switch tabs */ >+ if (!empathy_chat_window_has_focus (window)) { >+ priv = GET_PRIV (window); >+ empathy_chat_window_switch_to_chat (window, chat); >+ empathy_window_present (GTK_WINDOW (priv->dialog), TRUE); > >- gtk_widget_grab_focus (chat->input_text_view); >+ gtk_widget_grab_focus (chat->input_text_view); >+ } > } > >diff --git a/src/empathy-event-manager.c b/src/empathy-event-manager.c >index c108020..8da5a50 100644 >--- a/src/empathy-event-manager.c >+++ b/src/empathy-event-manager.c >@@ -361,11 +361,15 @@ static void > event_manager_chat_message_received_cb (EmpathyTpChat *tp_chat, > EmpathyMessage *message, EventManagerApproval *approval) > { >- EmpathyContact *sender; >- const gchar *header; >- const gchar *msg; >- TpChannel *channel; >- EventPriv *event; >+ EmpathyContact *sender; >+ const gchar *header; >+ const gchar *msg; >+ TpChannel *channel; >+ EventPriv *event; >+ >+ gboolean auto_open_chat; >+ TpConnectionPresenceType presence; >+ EmpathyIdle *idle; > > /* try to update the event if it's referring to a chat which is already in the > * queue. */ >@@ -377,7 +381,17 @@ event_manager_chat_message_received_cb (EmpathyTpChat *tp_chat, > > channel = empathy_tp_chat_get_channel (tp_chat); > >- if (event != NULL) >+ empathy_conf_get_bool (empathy_conf_get (), EMPATHY_PREFS_UI_AUTO_OPEN_CHAT, >+ &auto_open_chat); >+ >+ idle = empathy_idle_dup_singleton (); >+ presence = empathy_idle_get_state (idle); >+ g_object_unref (idle); >+ >+ /* Only auto-open chat window if enabled and we're not busy/do not disturb */ >+ if (auto_open_chat && presence != TP_CONNECTION_PRESENCE_TYPE_BUSY) >+ empathy_dispatch_operation_approve (approval->operation); >+ else if (event != NULL) > event_update (approval->manager, event, EMPATHY_IMAGE_NEW_MESSAGE, header, msg); > else > event_manager_add (approval->manager, sender, EMPATHY_EVENT_TYPE_CHAT, >diff --git a/src/empathy-preferences.c b/src/empathy-preferences.c >index 993cf77..55654f0 100644 >--- a/src/empathy-preferences.c >+++ b/src/empathy-preferences.c >@@ -55,6 +55,7 @@ typedef struct { > GtkWidget *checkbutton_show_contacts_in_rooms; > GtkWidget *combobox_chat_theme; > GtkWidget *checkbutton_separate_chat_windows; >+ GtkWidget *checkbutton_auto_open_chat; > GtkWidget *checkbutton_autoconnect; > > GtkWidget *checkbutton_sounds_enabled; >@@ -212,6 +213,10 @@ preferences_setup_widgets (EmpathyPreferences *preferences) > preferences->checkbutton_separate_chat_windows); > > preferences_hookup_toggle_button (preferences, >+ EMPATHY_PREFS_UI_AUTO_OPEN_CHAT, >+ preferences->checkbutton_auto_open_chat); >+ >+ preferences_hookup_toggle_button (preferences, > EMPATHY_PREFS_CHAT_SHOW_SMILEYS, > preferences->checkbutton_show_smileys); > >@@ -1139,6 +1144,7 @@ empathy_preferences_show (GtkWindow *parent) > "checkbutton_show_contacts_in_rooms", &preferences->checkbutton_show_contacts_in_rooms, > "combobox_chat_theme", &preferences->combobox_chat_theme, > "checkbutton_separate_chat_windows", &preferences->checkbutton_separate_chat_windows, >+ "checkbutton_auto_open_chat", &preferences->checkbutton_auto_open_chat, > "checkbutton_autoconnect", &preferences->checkbutton_autoconnect, > "checkbutton_notifications_enabled", &preferences->checkbutton_notifications_enabled, > "checkbutton_notifications_disabled_away", &preferences->checkbutton_notifications_disabled_away, >diff --git a/src/empathy-preferences.ui b/src/empathy-preferences.ui >index 2e32fe9..48f1f7c 100644 >--- a/src/empathy-preferences.ui >+++ b/src/empathy-preferences.ui >@@ -131,6 +131,21 @@ > <property name="position">1</property> > </packing> > </child> >+ <child> >+ <object class="GtkCheckButton" id="checkbutton_auto_open_chat"> >+ <property name="label" translatable="yes">Automatically open new chat window or tab</property> >+ <property name="visible">True</property> >+ <property name="can_focus">True</property> >+ <property name="receives_default">False</property> >+ <property name="use_underline">True</property> >+ <property name="draw_indicator">True</property> >+ </object> >+ <packing> >+ <property name="expand">False</property> >+ <property name="fill">False</property> >+ <property name="position">2</property> >+ </packing> >+ </child> > </object> > </child> > </object> >-- >1.6.3.3 >
Created attachment 148359 [details] [review] Fix commit message Argh. Did I mention I really hated Bugzilla?
*** Bug 602966 has been marked as a duplicate of this bug. ***
I'm not sure adding a preference here is desirable - could we just Do The Right Thing based on whether there is a notification icon visible or not? Adding Nick to CC to see if he has any insights.
(In reply to comment #34) > I'm not sure adding a preference here is desirable - could we just Do The Right > Thing based on whether there is a notification icon visible or not? Adding Nick > to CC to see if he has any insights. Not sure what you mean by "here", if you mean at a certain location or anywhere at all, but yes, we definitely need a preference somewhere. Why force the user into something, it will just annoy some users and only satisfy some. This does need to be a preference option.
I mean, whether it should be a preference at all, rather than something which behaves in an appropriate manner depending whether or not you have a notification icon. Your reasoning seems to be "it needs to be a preference because this is something that potentially annoys users" and doesn't hold in my opinion. If its annoying for lots of people, it should work properly for these people by default, and all the time, not after you dig in some dialog and toggle a checkbox. So the question I'm asking is, can we do better for more people than by making this a preference? Making a preference often is a cop out for working out what people really want and making the default behaviours better for everyone, rather than just the keen knob-twiddling users.
I agree. I think the default behaviour could definitely be improved. But considering the amount of people commenting on this bug and the strong preferences from both sides I just think it would be difficult to please everyone...I am not saying it is impossible but it would be incredibly difficult to be able to tweak the behaviour just right so that everyone is happy
*** Bug 603206 has been marked as a duplicate of this bug. ***
*** Bug 604578 has been marked as a duplicate of this bug. ***
I also vote for a popunder window for incoming chats. I use openbox and I barely even get to see the flashing message balloon.
Created attachment 150306 [details] [review] http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/popup-chat-585914-2 libempathy-gtk/empathy-conf.h | 1 + libempathy-gtk/empathy-ui-utils.c | 7 +++---- libempathy-gtk/empathy-ui-utils.h | 2 +- libempathy/empathy-dispatch-operation.c | 28 ++++++++++++++++++++++++++++ libempathy/empathy-dispatch-operation.h | 7 +++++++ src/empathy-chat-window.c | 10 ++++++---- src/empathy-chat-window.h | 3 ++- src/empathy-event-manager.c | 18 +++++++++++++++++- src/empathy-main-window.c | 3 ++- src/empathy-map-view.c | 6 ++++-- src/empathy-preferences.c | 6 ++++++ src/empathy-preferences.ui | 16 ++++++++++++++++ src/empathy-status-icon.c | 3 ++- src/empathy.c | 3 ++- 14 files changed, 97 insertions(+), 16 deletions(-)
The above branch implements this feature. According to my tests, incoming chats are sometimes popuped up (stealing the focus) and sometimes poped under (leaving the focus). I don't know if that's a bug in my code or because of my WM (metacity). Please test. Also, if someone with a better understanding of window manager and gtk_window_present_with_time could check this code, any input is more than welcome.
There's a bug in this branch that makes it so the first message of any conversation that creates a new tab (vs. creating a new window) does not set urgency, or update window/tab titles as if a new message was received. It appears that thew new-message signal is being missed, as it is connected to after the message is received. The signal is being fired on first message, there's just no one listening to it.
I've started a branch at http://gitorious.org/empathy-lamalex/empathy-lamalex/commits/new-conv-new-window-585914 which continues work on this, and follows an up to date master.
Here's the ideal behavior: When a new message is coming in that starts a new message, pop a new IM chat window on top of everything else, but don't steal focus. When a new message is coming in within an existing discussion, raise the IM chat window on top of everything else, but don't steal focus. Of course, all this should be configurable from within the IM application, maybe some other people prefer other notification policies. The policy I describe is best in the environment I use IM (at work, IMs are from coworkers, I don't get a lot of messages per day but when I do get them I MUST NOT miss them!) The don't steal focus is especially important for those using a focus-follows-mouse setting, but I guess it's useful anyway. The current notification methods (Empathy 2.28.1.1) are useless. People think I'm avoiding their IMs on purpose. :( I had to go back to Pidgin, which is not ideal either but just somewhat better.
Raising on every new message is *not* ideal, if you have a conversation open then the URGENT hint should be sufficient. Imagine how obnoxious it would be if every time you clicked off of the chat window, it popped back up.
Fine. Make it a setting, let ME (the user) choose.
I hope a fix for this issue will also fix the following, which I observe in empathy 2.30.0 as packaged in Ubuntu Lucid. I can't tell if it has been covered by the comments above. To reproduce: 1. Open a conversation with User A and chat. 2. User B sends a message while conversation window is active. Expected: a new tab opens in the conversation window with User B's message, but User A's tab remains active. Observed: must click on a notification area / messaging menu icon to read User B's message. The expected behaviour here seems less controversial than some of the cases above where the conversation window does *not* have focus when User B's message arrives.
yeah, we're all waiting for this down in papercuts on launchpad.. i'll notify the subscribers that here's the place to follow now..pretty upstream empathy ;) we all know what's to be done. netbooks and subnotebooks are gradually all beginning to abandon panels, raising windowlists and main menus only on demand. notification is becoming more dynamic and less obtrusive, things are taking shape for an intelligent interactive behaviour of our desktop. thanks also to Alex for putting so much energy into this!
Forgot about the patches/branches linked above. Once we'll have proper approver (bug #599158) this will become trivial to do by implementing a small auto-approver.
Hi, I would like to add my voice for the need for this bug to be fixed. Having to locate the Notification area and the correct icon for screenreader users to find out who messaged, and to open a window for a reply is particularly cumbersum. With this in place, empathy would improve considerably for Orca users. Thanks for your time.
As said, once bug #599158 will be fixed this will become trivial to implement.
I have a start of a branch implementing this but I'm not sure of the best way to phrase this option. Any suggestion?
I had "Place new conversations in status icon until I accept them" in my branch when I was working on this.
(In reply to comment #54) > I had "Place new conversations in status icon until I accept them" in my branch > when I was working on this. To be clear; I was working with conversations pop up automatically as the default behavior.
Created attachment 165343 [details] [review] http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/auto-popup-585914 data/org.gnome.Empathy.gschema.xml.in | 6 +++ libempathy-gtk/empathy-ui-utils.c | 12 ++++++- libempathy/empathy-gsettings.h | 1 + src/empathy-event-manager.c | 55 +++++++++++++++++++++++++++++++-- src/empathy-preferences.c | 8 +++++ src/empathy-preferences.ui | 17 +++++++++- 6 files changed, 93 insertions(+), 6 deletions(-)
Here is an implementation of this. I phrased the option "Display incoming events in the notification area" but I'm open for a better suggestion.
I think "Display incoming events in the notification area" is a little unclear. It doesn't imply that the alternative is to open in a new window. How about "Open a new window for each new conversation"? It still seems a little awkward. Pidgin's option is worded "Hide new IM conversations". Thanks for your work.
Review of attachment 165343 [details] [review]: Some small points. Otherwise looks fine. ::: data/org.gnome.Empathy.gschema.xml.in @@ +76,3 @@ <_description>Always open a separate chat window for new chats.</_description> </key> + <key name="events-notif-area" type="b"> "notify" instead of "notif" might by clearer? ::: src/empathy-event-manager.c @@ +239,3 @@ priv->events = g_slist_prepend (priv->events, event); + + if (!display_notif_area ()) Again "notify" might be clearer.
(In reply to comment #58) > How about "Open a new window for each new conversation"? It still seems a > little awkward. Pidgin's option is worded "Hide new IM conversations". Thanks > for your work. I don't like either of those as it's not only about IM but all the incoming events (file transfer, calls, etc). Furthermore, this could be confused with the existing "Open chats in separated windows". I think I'll keep the current phrasing for now. We still have plenty of time to change before the 3.0 release.
(In reply to comment #59) > Review of attachment 165343 [details] [review]: > > Some small points. Otherwise looks fine. > > ::: data/org.gnome.Empathy.gschema.xml.in > @@ +76,3 @@ > <_description>Always open a separate chat window for new > chats.</_description> > </key> > + <key name="events-notif-area" type="b"> > > "notify" instead of "notif" might by clearer? > > ::: src/empathy-event-manager.c > @@ +239,3 @@ > priv->events = g_slist_prepend (priv->events, event); > + > + if (!display_notif_area ()) > > Again "notify" might be clearer. Thanks, I changed that and merged the branch. 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.
*** Bug 629336 has been marked as a duplicate of this bug. ***
This bug has been un-fixed in GNOME3 versions of Empathy. It should be reopened.
The option "display incoming events in the notification area" is no more available in last Empathy 3.6.3 shipped in Ubuntu Raring, so no more way to "force" any incoming message to put the chat window on the focus when Empathy is in the background ! The only indication goes on the MeMenu and I missed it often. There are no more notifications, too (bubbles on the top right corner via libnotify), as there are in Pidgin and I did not find any way to configure them, only sounds can be. Well, is Empathy going like other Gnome apps (as Nautilus) and come with less and less functions or customization at each new version ? Why not let the user choose what he prefers as options ? So is there a way to have this back in Ubuntu (via Dconf or everything else) ? Thanks for your help.