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.
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?
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.
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.
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.
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 :)
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.
I'm working on this, but there's a lot of 0's to change :(
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
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.
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.
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
*** Bug 85976 has been marked as a duplicate of this bug. ***
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.
*** Bug 87324 has been marked as a duplicate of this bug. ***
kmail does that to me too. ksystray dont give focus to application without closing popup message first. which sleep in the background. priority HIGH
*** Bug 87647 has been marked as a duplicate of this bug. ***
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!
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.
see also http://galago.sourceforge.net/specs/notification/index.php that could be implemented in KDE when it support DBUS (KDE4?)
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.
> 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.
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.
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
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.
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?
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?
*** Bug 81367 has been marked as a duplicate of this bug. ***
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...
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.
*** Bug 101411 has been marked as a duplicate of this bug. ***
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.
*** Bug 103533 has been marked as a duplicate of this bug. ***
*** Bug 102444 has been marked as a duplicate of this bug. ***
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.
This does not happen in KDE 4.6.1. Closing the bug, reopen it if you think it still valid.