Bug 74075 - Message boxes steal focus from the 'New Message' balloon
Summary: Message boxes steal focus from the 'New Message' balloon
Status: RESOLVED FIXED
Alias: None
Product: kopete
Classification: Applications
Component: libkopete (show other bugs)
Version: SVN
Platform: unspecified All
: NOR normal
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
: 81367 85976 87324 87647 101411 102444 103533 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-03 20:50 UTC by Iván Sánchez Ortega
Modified: 2011-03-20 21:36 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
turn modal message boxes into async notifications (907 bytes, patch)
2004-12-17 21:32 UTC, mi+kde
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Iván Sánchez Ortega 2004-02-03 20:50:32 UTC
Version:           0.8.0 (using KDE 3.2.0,  (testing/unstable))
Compiler:          gcc version 3.3.3 20040110 (prerelease) (Debian)
OS:          Linux (i686) release 2.4.22-xfs

This bug is quite annoying. Do the following to reproduce it:

- Configure Kopete so that you use a crappy server, or otherwise make it pop some server error dialog window. Most MSN servers will do fine for this purpose, as I cannot login to them 50% of the time.
- Go on-line. A protocol error pop-up should raise.
- Wait for a friend of yours (or a bot) to send you a message. JabRSS bot is doing fine for me. Watch the yellow blob appear.
- And now comes the funny part: Whenever the yellow blob and the protocol error dialog are on the screen, you can't click on the yellow blob! (Well, you can, but the error dialog will steal its focus, and your click will be lost in /dev/null).

I found this specially annoying because I run Kopete in a virtual desktop, while doing the work in another. The yellow blob shows up, but the protocol error pop-up, even being in other virtual desktop (!) steals the focus.
A newbie should anger and shout "Dissapear you damn yellow blob!!", because he/she wouldn't see the protocol error dialog window.
Comment 1 Jason Keirstead 2004-02-03 20:55:02 UTC
Subject: Re: [Kopete-devel]  New: Protocol error pop-ups steal focus from Kopete's yellow "incoming message" blob

On February 03, 2004 3:50 pm, Iván Sánchez Ortega wrote:
> - Wait for a friend of yours (or a bot) to send you a message. JabRSS bot
> is doing fine for me. Watch the yellow blob appear. - And now comes the
> funny part: Whenever the yellow blob and the protocol error dialog are on
> the screen, you can't click on the yellow blob! (Well, you can, but the
> error dialog will steal its focus, and your click will be lost in
> /dev/null).

This is due to the fact that these protocol errors are using 0L for their 
widget parent, so they are application modal.

All error dialogs that don't have an obvious widget parent should use the main 
Kopete window. But a) I don't know if there's an easy way to access this? b) 
What do you use when the window is hidden?

Comment 2 Martijn Klingens 2004-02-03 21:19:03 UTC
Subject: Re: [Kopete-devel]  Protocol error pop-ups steal focus from Kopete's yellow "incoming message" blob

On Tuesday 03 February 2004 20:55, Jason Keirstead wrote:
> a) I don't know if there's an easy way to access this?

No, there isn't. The async plugin loader adds a reference to KApplication and 
KApp's refcounting doesn't properly work when using mainWidget().

Thus, there's no mainWidget() anymore.

I want to add our own method to return it somewhere, but how do we define 
"somewhere"? Can't think of a suitable class :(

> b) What do you use when the window is hidden? 

The same, a hidden window makes the message box still pop up, but not 
app-modal, stealing focus.

Comment 3 Iván Sánchez Ortega 2004-02-03 21:32:14 UTC
Subject: Re:  Protocol error  pop-ups steal focus from Kopete's yellow "incoming message" blob

> All error dialogs that don't have an obvious widget parent should use the
> main Kopete window. But a) I don't know if there's an easy way to access
> this? b) What do you use when the window is hidden?

a) Maybe using standard "gray boxes" instead of yellow blobs (like Juk's or 
when, in Kopete, someone goes online) ??  (I don't know much about the 
architecture of QT/KDE, nor if this could be a solution)
Maybe making the protocol error a "grey box" pop-up??  (should not be good for 
debugging or read what is causing the error)
Maybe making the protocol error dialog present in all virtual desktops??  
(quite intrusive, I wouldn't like the idea)


b) When the main Kopete window (and the protocol error dialog) are hidden (in 
other virtual desktop), and I realize that something is stealing the focus, I 
switch to Virtual Desktop 2, close the protocol error dialog, and keep 
rolling as usual. 
The problem is: a newbie hardly could realize that something is stealing the 
focus, switch to the right virtual desktop, and close the error dialog.


By the way, I am using a CVS snapshot for Debian - Kopete and Kdelibs are 
CVS20041226 , not the official 3.2.0 release.

Comment 4 Jason Keirstead 2004-02-03 21:42:48 UTC
Subject: Re: [Kopete-devel]  Protocol error pop-ups steal focus from Kopete's yellow "incoming message" blob

On February 03, 2004 4:19 pm, Martijn Klingens wrote:
> I want to add our own method to return it somewhere, but how do we define
> "somewhere"? Can't think of a suitable class :(

KopeteGlobal::mainWidget()

Other global things can also be here.. all our singletons

KopetePrefs * KopeteGlobal::prefs();
KopeteContactList *KopeteGlobal::contactList();
KopeteMessageManagerFactory *KopeteGlobal::messageManagerFactory()
..etc.

You can then make the singleton constructor functions for those objects 
private and make KopeteGlobal a friend of those classes.

Would seem very clean to me, and very KGlobal-ish.


Comment 5 Martijn Klingens 2004-02-03 21:48:04 UTC
Subject: Re: [Kopete-devel]  Protocol error pop-ups steal focus from Kopete's yellow "incoming message" blob

On Tuesday 03 February 2004 21:42, Jason Keirstead wrote:
> Would seem very clean to me, and very KGlobal-ish.

Yeah, neat idea.

One wish from me:

Split into KopeteGlobalCore and KopeteGlobalUI or so, so we don't close the 
door to splitting GUI from logic.

Not absolutely necessary (forward declare the pointer and return NULL in the 
non-gui case), but seems cleaner.

Apart from that I'm all for it. Who does the honours? You or me (this weekend 
then :)

Comment 6 Richard Smith 2004-02-12 03:38:04 UTC
Does someone with a free moment want to do this? I would, but I'm off to bed now... :) Also, are we backporting this one? Wouldn't be hard, but it would mean backporting kopeteuiglobal.{h,cpp} as well, and the (non-trivial) changes to kopete/kopete.cpp and kopete/main.cpp.
Comment 7 Richard Smith 2004-02-14 18:26:50 UTC
I'm working on this, but there's a lot of 0's to change :(
Comment 8 Richard Smith 2004-02-14 21:55:03 UTC
CVS commit by lilachaze: 

Use Kopete::UI::Global::mainWidget() wherever we should.
This makes absolutely no difference to bug 74075, but seems worth doing
anyway.
CCMAIL: 74075@bugs.kde.org


  M +3 -2      kopete/kopeteiface.cpp   1.35
  M +1 -1      kopete/kopetewindow.cpp   1.179
  M +8 -7      kopete/contactlist/kopetecontactlistview.cpp   1.75
  M +2 -1      kopete/contactlist/kopetemetacontactlvi.cpp   1.63
  M +4 -3      libkopete/kopetecontact.cpp   1.178
  M +2 -1      libkopete/kopetemessagemanager.cpp   1.192
  M +3 -2      libkopete/kopetemetacontact.cpp   1.202
  M +12 -10    libkopete/kopetenotifyclient.cpp   1.8
  M +2 -1      libkopete/kopetetransfermanager.cpp   1.24
  M +2 -1      libkopete/private/kopetecommand.cpp   1.12
  M +2 -1      libkopete/ui/kopetestdaction.cpp   1.51
  M +2 -1      libkopete/ui/userinfodialog.cpp   1.13
  M +2 -1      plugins/cryptography/cryptographyplugin.cpp   1.43
  M +3 -2      plugins/history/converter.cpp   1.7
  M +3 -2      plugins/history/historyplugin.cpp   1.21
  M +2 -1      plugins/netmeeting/netmeetinginvitation.cpp   1.6
  M +2 -1      protocols/gadu/gaduaccount.cpp   1.94
  M +1 -1      protocols/irc/ircaccount.cpp   1.73
  M +5 -4      protocols/irc/ircchannelcontact.cpp   1.95
  M +1 -1      protocols/irc/libkirc/kircmessage.cpp   1.16
  M +21 -20    protocols/jabber/jabberaccount.cpp   1.85
  M +3 -2      protocols/jabber/jabbercontact.cpp   1.163
  M +5 -4      protocols/msn/msnaccount.cpp   1.63
  M +2 -1      protocols/msn/msnaddcontactpage.cpp   1.27
  M +4 -2      protocols/msn/msnauthsocket.cpp   1.23
  M +4 -3      protocols/msn/msncontact.cpp   1.159
  M +2 -1      protocols/msn/msnmessagemanager.cpp   1.92
  M +20 -19    protocols/msn/msnnotifysocket.cpp   1.132
  M +4 -2      protocols/msn/msnsocket.cpp   1.85
  M +6 -5      protocols/msn/msnswitchboardsocket.cpp   1.96
  M +3 -1      protocols/msn/ui/msneditaccountwidget.cpp   1.19
  M +3 -2      protocols/oscar/oscaraccount.cpp   1.104
  M +3 -2      protocols/oscar/oscarcontact.cpp   1.143
  M +3 -2      protocols/oscar/aim/aimaccount.cpp   1.29
  M +4 -3      protocols/oscar/aim/aimcontact.cpp   1.44
  M +2 -1      protocols/oscar/icq/icqcontact.cpp   1.44
  M +2 -1      protocols/sms/serviceloader.cpp   1.12
  M +3 -1      protocols/sms/smsaccount.cpp   1.14
  M +3 -2      protocols/sms/smscontact.cpp   1.50
  M +3 -1      protocols/sms/smseditaccountwidget.cpp   1.12
  M +2 -1      protocols/sms/services/smsclient.cpp   1.21
  M +3 -2      protocols/sms/services/smssend.cpp   1.22
  M +3 -2      protocols/sms/services/smssendprovider.cpp   1.34
  M +3 -2      protocols/winpopup/wpprotocol.cpp   1.57
  M +3 -2      protocols/yahoo/yahooaccount.cpp   1.64



Comment 9 Richard Smith 2004-02-15 04:07:06 UTC
So, to solve this, I see 4 possibilities:
1) Make the balloon clickable when a modal dialog is up (how? also has the nested-event-loop problem)
2) Make clicking the balloon pull the message box to the front and ensure it's on the current display
3) Make all our message boxes modeless
4) Don't use nasty modal message boxes at all - use KNotify for all error messages and such, or some other mechanism

Option 1 is probably easiest if it's possible at all (but might not be)... unfortunately we'll then get reports of "Protocol error pop-ups steal focus from Kopete's Contact List" and so on. Modal messages are just plain wrong for this case. Options 3 and 4 require not using KMessageBox directly any more (no bad thing IMO). Option 2 looks to require some KWin hacking.

My preferred option is option 4. We can add a message() signal to KopeteAccount and KopetePlugin, and do whatever we want with them in libkopete (for instance, show a modeless message box, or send them to KNotify, or to some logging widget somewhere, or whatever). There's the issue of message boxes which require a response (for instance Jabber's "A user has added you to their contactlist. Add them in return?" message) but only a handful of these occur spontaneously, and they can probably all be made modeless.

The core of the problem is that spontaneously popping up dialogs is a bad idea, whether or not they're modal, unless the user really needs to be told *right now* (eg, "your computer is overheating!"). Anyway, the current behaviour is the best we can do without considerably more work IMO.
Comment 10 Martijn Klingens 2004-02-15 10:54:15 UTC
On Sunday 15 February 2004 04:07, Richard Smith wrote:
> The core of the problem is that spontaneously popping up dialogs is a bad
> idea, whether or not they're modal, unless the user really needs to be told
> *right now* (eg, "your computer is overheating!").

Right.

Therefore there should be some methods in libkopete for signalling messages to 
the user and the plugins should no longer use KMessageBox directly.

Kopete can then have centralized code that handles the message box so you 
don't have to grep all over the place.

Whether the message box is a message box, a passive popup, or whatever can be 
determined next.

Comment 11 Martijn Klingens 2004-02-15 13:41:38 UTC
Moving to libkopete, because we first need the groundwork there.

Also removing the Kopete 0.8 version since it's *highly* unlikely the fix can be backported there. Seems to be something that we need to fix for Kopete 0.9.

Martijn
Comment 12 Will Stephenson 2004-07-26 08:52:08 UTC
*** Bug 85976 has been marked as a duplicate of this bug. ***
Comment 13 Richard Smith 2004-08-03 16:46:02 UTC
We could add contacts to the contact list (or a separate list) for each account, and have the messages come from them (exactly like Jabber transports). Wherever we put them, we should also put Jabber transports and any other system contacts there too.

For the messages that need a reply, we can have a link in the message body, like:

You have been added to the contact list of the Jabber user 'example@jabber.com'. You might want to:
<ul>
 <li><a ...>View information about this person</a></li>
 <li><a ...>Allow this person to see whether I am online</a></li>
 <li><a ...>Block this person from seeing whether I am online</a></li>
 <li><a ...>Add example@jabber.com to your contact list</a></li>
<ul>

With a little work, we could make the links function persistently so they'd work from the history in a later session too.

A simple grep across protocols/ indicates this sort of thing ought to work for some uses of KMessageBox::question*, some others can be cured by some libkopete work, and three remain:

1) SMS asks 'Do you want to split this message up?' if it's too long. There's a well-established SMS standard for how to send long messages (prepending Linked n/m to the messages), which we should probably just use.
2) AIM's warn user question: warn anonymously or warn with your name. This could be fixed as above; not sure how intuitive that'd be.
3) Oscar's "Are you sure you want to establish a direct connection to this user?" dialog. In this case the user's asked us to open a chat session, so we could start that session with this question, and not establish a connection until the user clicks the link in the message.
Comment 14 Richard Smith 2004-08-17 02:15:27 UTC
*** Bug 87324 has been marked as a duplicate of this bug. ***
Comment 15 Mathieu Jobin 2004-08-20 05:21:07 UTC
kmail does that to me too.
ksystray dont give focus to application without closing popup message first. which sleep in the background.

priority HIGH

Comment 16 Richard Smith 2004-08-21 03:03:28 UTC
*** Bug 87647 has been marked as a duplicate of this bug. ***
Comment 17 mi+kde 2004-10-16 00:35:45 UTC
I think, the warnings and erros should show up just like new messages do. MSN is, indeed, the worst offender. The Yahoo! and AOL's system messages appear nicely and obstruct other chats. Please fix... Thank you!
Comment 18 Richard Smith 2004-11-07 14:50:28 UTC
I'd like some feedback on Comment #13 from other developers. I'm currently thinking we could make the proposed 'account contacts' act like IRC's server window, to hide them from the user most of the time.
Comment 19 Olivier Goffart 2004-11-07 15:45:31 UTC
see also http://galago.sourceforge.net/specs/notification/index.php that could be implemented in KDE when it support DBUS (KDE4?)
Comment 20 Richard Smith 2004-11-07 16:17:30 UTC
On Sunday 07 November 2004 14:45, Olivier Goffart wrote:
> see also http://galago.sourceforge.net/specs/notification/index.php
> that could be implemented in KDE when it support DBUS (KDE4?)

That'd be a nice solution. However, a galago implementation isn't required to 
support actions on a notification. We could detect this and do something 
different, or just live with it.
Comment 21 Olivier Goffart 2004-11-07 16:37:50 UTC
> galago implementation isn't required to support actions on a notification.


Even if it's hosted on galago server, and devloped by the same guy,  galago, and that notification specification are two differents things

> We could detect this and do something different, or just live with it. 

They plan to finaly require it in the final specification.
If they don't, the KDE client library will track it, and display uses a messagebox instead. (as the specification say)
 
anyway, what we could do now is just wait dbus support in kde.
I already proposed myself to develop a kde client and server for that spec.
Comment 22 Richard Smith 2004-11-07 19:44:10 UTC
On Sunday 07 November 2004 15:37, Olivier Goffart wrote:
> > We could detect this and do something different, or just live with it.
>
> They plan to finaly require it in the final specification.
> If they don't, the KDE client library will track it, and display uses a
> messagebox instead. (as the specification say)

OK. This is now sounding ideal for our purposes. In the meantime we could 
implement a framework in libkopete for this and port the protocols to it to 
make adopting a notification system easier.
Comment 23 Mathieu Jobin 2004-11-07 20:48:16 UTC
i think this problem is not only related to kopete but all systray app.

modal messsage box prevent systray icon to hide/show mainwindow.
or any interraction from the systray to the application

you have to find the message box, and OK it

I have same problem with kmail and others applications too

Comment 24 Richard Smith 2004-11-07 20:59:10 UTC
On Sunday 07 November 2004 19:48, Mathieu Jobin wrote:
> i think this problem is not only related to kopete but all
> systray app.

Not just systray apps; all applications have the problem that you can't 
interact with the UI when a message box is visible. Like in Konqueror where 
it looks like it's hanging while waiting for you to deal with the cookie 
popup.
Comment 25 Jason Keirstead 2004-11-08 14:12:38 UTC
On Sunday 07 November 2004 9:50 am, Richard Smith wrote:
> ------- Additional Comments From kde metafoo co uk  2004-11-07 14:50
> ------- I'd like some feedback on Comment #13 from other developers. I'm
> currently thinking we could make the proposed 'account contacts' act like
> IRC's server window, to hide them from the user most of the time.

I have one problem with the idea of system messages and prompts coming up in 
the chat window - if you have the queue enabled and no chat open it would be 
extremely weird IMO - a message bubble shows up, you click it, and.. .its a 
system message??

Maybe we can design a mechanism whereby if a chat is already open, *then* we 
put it in the chat, otherwise, it shows up in a KDialog?


Comment 26 Richard Smith 2004-11-08 14:25:34 UTC
On Monday 08 November 2004 13:15, Jason Keirstead wrote:
> On Sunday 07 November 2004 9:50 am, Richard Smith wrote:
> > I'd like some feedback on Comment #13 from other developers. I'm
> > currently thinking we could make the proposed 'account contacts' act like
> > IRC's server window, to hide them from the user most of the time.
>
> I have one problem with the idea of system messages and prompts coming up
> in the chat window - if you have the queue enabled and no chat open it
> would be extremely weird IMO - a message bubble shows up, you click it,
> and.. .its a system message??

That's a good point. The desktop notifications (a la galago) solution has my 
vote.

> Maybe we can design a mechanism whereby if a chat is already open, *then*
> we put it in the chat, otherwise, it shows up in a KDialog?

For something like file transfer notifications, this definitely makes sense, 
as it would be quite cool to have such messages appear in the chat. Maybe we 
do a desktop notification regardless, and send an internal message to the 
chat if it's already open?
Comment 27 Olivier Goffart 2004-11-28 22:33:19 UTC
*** Bug 81367 has been marked as a duplicate of this bug. ***
Comment 28 mi+kde 2004-12-17 21:32:06 UTC
Created attachment 8704 [details]
turn modal message boxes into async notifications

How about this simple patch, addressing the immediate and pressing problem
caused by the MSN's message 715?

Frankly, I'm quite astounded, that nothing like this was put in place long ago
to solve 90% of the problem for 90% of the users...
Comment 29 mi+kde 2004-12-25 18:05:27 UTC
I must admit, that my patch above (id=8704) *completely* shuts off the 715 messages -- instead of making them appear unobtrusively like Yahoo! mail's.

I find that the current behavior is still a big improvement for I don't care to see these stupid reminders, but a KDE expert needs to take a look into why the KNotifyClient::event call is not doing anything at all.
Comment 30 Olivier Goffart 2005-03-15 23:32:13 UTC
*** Bug 101411 has been marked as a duplicate of this bug. ***
Comment 31 Rob Hughes 2005-03-30 01:55:31 UTC
Just please please please please, while you're working on this, fix the problem the dialogs popping up over and over again, especially when kopete gets disconnected (as in Bug 101411). I really don't need kopete to tell me 100 times that there was an error connecting. Once is enough, then make it stop until another connection is attempted by the user. Anything more than one connection error message is just poor design IMO.
Comment 32 Olivier Goffart 2005-04-09 10:08:06 UTC
*** Bug 103533 has been marked as a duplicate of this bug. ***
Comment 33 Olivier Goffart 2005-04-18 16:01:47 UTC
*** Bug 102444 has been marked as a duplicate of this bug. ***
Comment 34 Unknown 2006-01-13 20:27:25 UTC
This is still a problem in KDE3.5, and it is not only annoying to newbies. It happens fast that you oversee a error and you are wondering why nothing is working anymore (e.g. writing a message in a chat window or if you want to open your contact list and it is just not appearing)

If the window is stealing the focus, it should at least come to the front so I can see it (don't know how to handle this with multiple desktops)

An option to disable (some of) these messages would also be nice. Most of them are notifications anyway (and only allow to press an ok button), like the status change of a contact. In fact, it is just a status change of a user: me! So why not using the same mechanism here?

nice would be a consistent way of informing the user, anyway. Right now there are 3 different ways: bubbles for messages, boxes for status changes and error windows for errors.
an idea would be stacking of small notification windows like e.g. Trillian is doing this. that way it would also solve the problem of covering one another.
Comment 35 Lamarque V. Souza 2011-03-20 21:36:19 UTC
This does not happen in KDE 4.6.1. Closing the bug, reopen it if you think it still valid.