Version: 7.2 (using KDE KDE 3.1.3) Installed from: Debian testing/unstable Packages OS: Linux Hi! I think the message notification (on taskbar icon) isnt working properly. As long as the message window with an user is open, you are not notified of new messages. I believe that the proper behavior in all the IM clients is to send notification unless the window with the user exists AND is keyboard-input focused.
Yeah this makes sense. I have 'Mark taskbar entry' but it never works. The conversation windows are usually behind other windows and whenever an incoming message arrives (I have explicetly made sure to enable the notification for this event) all I get is sound and no visual notification. This is with a completely new kde cvs build as well.
Ok, after a bit of experimenting, I found that if I have taskbar grouping set I get no visual notification. Could you try turning grouping off and seeing if that fixes the problem?
If the only problem is that needsAttention doesn't work with taskbar grouping, then this is a kicker bug not a Kopete bug.
Another comment: I know both sounds and passive popups work fine, regardless of if the window is focused or not. The systray icon however, does not flash on new messages if a window is already open for that contact. This is by design and is how most IM clients operate. NOTE: The event for "message recieved" is different from the event "new message without an open window". The new message without an open window, the one that will show a bubble and/or flash the tray is a "Sound notification for Kopete events" event The new message one that always fires is the New message event.
> The systray icon, does not flash on new messages if a window is > already open for that contact. I think this is the whole point of this bug report. If this is an exepted behavior, then, we can close this bug.
>The systray icon however, does not flash on new messages if a window is >already open for that contact. This is by design and is how most IM clients >operate. I dont see how this can be an expected behavior! Irc may operate like this, but not the rest of the IM clients. (At least not the windows ones, gaim or sim) If you are on desktop 1 chatting with somebody, and then go to desktop 3 to do something else, or even switch to another app on the same desktop.. I expect a visual notification on the System Tray on new messages (so, with either clicking on it or using the proper shortcut i can raise that chat window), Otherwise I have no idea that the message arrived. Using the "automatic raise chat window on message" can be overly annoying to many people, so I dont think it is a solution. This has nothing to do with kicker, it's simply checking if a window where a chat with that person is open upon message arrival, and then if using QWidget::hasFocus() on it return false, the system tray should be put to flash. If you dont think using hasFocus() is right, then at least isVisible() should be used!
Subject: Re: [Kopete-devel] Improper message notification behavior On October 09, 2003 9:41 am, Juan Linietsky wrote: > I dont see how this can be an expected behavior! Irc may operate like this, > but not the rest of the IM clients. (At least not the windows ones, gaim or > sim) I can tell you now that they do. Gaim and Windows ICQ and Windows MSN all behave this way. The "popup" notification (a-la our bubble) and/or the system tray notification only happen if theres no open window for that guy. If there is, all they do is flash the taskbar and/or make a sound. > If you are on desktop 1 chatting with somebody, and then go to desktop > 3 to do something else, or even switch to another app on the same desktop.. > I expect a visual notification on the System Tray on new messages (so, with > either clicking on it or using the proper shortcut i can raise that chat > window), So go turn on the passive popups for the notifications on new messages! "Configure Sounds & Events" under Behaviour -> More Options, and select "Incoming Message Arrives", and check Mark Taskbar and/or any other stuff. I suggest passive popups. You can even run your own shell scripts. You could make your desktop vibrate whenever a new message appears using DCOP. You can do *anything you want*. Honestly I am getting really sick of all these notification bug reports from people who don't know what you can do with KNotify. Someone needs to add a FAQ entry for this type of stuff or we need to make it more apparent in the interface.
Subject: Re: [Kopete-devel] Improper message notification behavior On Thursday 09 October 2003 14:53, Jason Keirstead wrote: > Honestly I am getting really sick of all these notification bug reports from > people who don't know what you can do with KNotify. Someone needs to add a > FAQ entry for this type of stuff or we need to make it more apparent in the > interface. It could also mean that 1. Our default config is broken since 90% of an app's users doesn't change defaults 2. It's a Kopete usability problem that people don't look in KNotify for the settings 3. It's a KNotify usability problem to configure it in the first place. I'm tempted to say all 3 are true. On 2 I'm not sure, 1 at least WAS true until Carsten turned the flashing on yesterday, and might still be, and 3 almost certainly is true, KNotify is a GUI bitch to operate.
Subject: Re: [Kopete-devel] Improper message notification behavior On October 09, 2003 10:17 am, Martijn Klingens wrote: > It could also mean that > 1. Our default config is broken since 90% of an app's users doesn't change > defaults With the addition of the flashing patch our behaviour matches most all IM clients I know of. As I said above, no im client *always* flashes the systray on every message, as well I dont think it is desireable to have a default popup appear on every new message, they can get annoying. However, since many users seem to want some kind of popup I think a FAQ entry would be a good idea. > 2. It's a Kopete usability problem that people don't look in KNotify for > the settings This is a big pat of it I suspect. "Configure Sounds & Events" just doesn't indicate to me that I can enable a popup window in there. Maybe it needs an extended tooltip on the button? Or maybe the user manual we are working on will solve all this. THis assumes people will actually read it before posting bugs (not likely :P) > almost certainly is true, KNotify is a GUI bitch to operate. I always found it quite simple to operate. The thing is getting the word out there that it IS there at all, and all the things it can do. KNotify is extremely powerfull. There is no collary to it in Gnome or Windows, people aren't used to be able to do so many things on events, they think KNotify is only for sounds. It doesn't help that it is listed under Sounds & Multimedia in KControl either. Its closer to Appearance & Themes than Sounds and events. It is very simmilar to Launch Feedback. Maybe it and Launch Feedback should be in their own catagory. I duno but Sounds it not the place for it because it's very misleading as to what it can do.
Subject: Re: [Kopete-devel] Improper message notification behavior On Thursday 09 October 2003 15:31, Jason Keirstead wrote: > Or maybe the user manual we are working on will solve all this. THis assumes > people will actually read it before posting bugs (not likely :P) If you need a manual or an FAQ the usability is broken. Better fix that instead. > I always found it quite simple to operate. It's uebercomplex actually. It has way too many widgets and options for a first-timer, and certainly for a non-advanced user.
Subject: Re: [Kopete-devel] Improper message notification behavior On October 09, 2003 11:09 am, Martijn Klingens wrote: > > I always found it quite simple to operate. > > It's uebercomplex actually. It has way too many widgets and options for a > first-timer, and certainly for a non-advanced user. Thats actually the oppposite of the real problem. Hiding things away more will only exasperate it. Look at all these bug reports we are getting because people don't know they can set popups in KNotify Thats because it is so hidden away. First you need to bring up the dialog. Then you need to click "More Options" to go into the advanced mode. Then you need to realize that you need to click the popup window checkbox to see the passive popup one, since it is greyed out and not very readable All this baloney just to turn on something like a passive popup, something it seems a lot of people want. Ther problem is this stupid "More Options" button, specifically the labeling. If you are looking at a screen that only deals with sounds, why on earth would you expect More Options to show you all this stuff regarding Logging and Popups etc? You'd expect it to show you different things relating to the sounds. Since the stuff is all in a group box labeled "Actions", the button should say "More Actions", not more options. As for the "turn on/off all" things, those are just wastes of space. They could be replaced with right click options on the icons in the QListView header that lists all the actions (eg, right click on the speaker option would give you "Turn on all sounds" and "Turn off all sounds" etc.
I agree with what has been said :) But we haven't gotten word back if Grouping tasks in kicker exposes a bug in knotify or not. To comment #6, I had your same exact problem but as soon as I told the kicker's taskbar to NOT always group tasks by default the problem disappeard. It should not be like this and there _may_ be a kicker/taskbar - knotify interaction bug -- which would affect ALL applications who try to do this.
Subject: Re: [Kopete-devel] Improper message notification behavior Executive summary: too many knobs and handles. Ergo: it's uebercomplex.
Closing this bug since it just descended into a criticism of KNotify's UI, which is really beyond the scope of the bug. All the issues presented in the original bug have been rectified.
> Closing this bug since it just descended into a criticism of KNotify's UI Then the correct verdict is INVALID, not FIXED.
Invalid.
I am reopening this bug because now that I re-read, there probably is a misunderstanding..... I and many other guys I know have been using "sim" since, because of kopete's lack of the feature. Kopete is an awesome app, but the lack of this makes it more bloated/complicated than what I'd expect it to be. I will try to be more clear this time: I SAID: The systray icon however, does not flash on new messages if a window is already open for that contact. This is by design and is how most IM clients operate. "Jason Keristead" replied: I can tell you now that they do. Gaim and Windows ICQ and Windows MSN all behave this way. The "popup" notification (a-la our bubble) and/or the system tray notification only happen if theres no open window for that guy. If there is, all they do is flash the taskbar and/or make a sound. --- Now, there is a misunderstanding here. While I agree with jason, the behavior is more complicated. The kopete system tray needs to STILL flash if the window of the chat is not focused or at least not visible.. so i'll make it more clear. first, I want to make the definition of "reading a message" as having the window FOCUSED (or at least VISIBLE), with the tab of the user from where the message comes selected, so you can SEE the text. so granted this, the logic should be: WHEN a message is received... THEN WHILE the user DID NOT READ the message, DO FLASH the traybar icon it's simple as this.. if you are already seeing the message, the traybar will never flash. and also.. clicking on the flashing traybar should take you to the first message on the queue. If this cant be implemented, i'd at least would like to hear a good reason about why not.. instead of telling me to use the popups, which i already used for months and couldnt get used to (to later ditch kopete for sim). If it's about programmer-time, I can implement the feature myself and submit a patch, as long as I am promised that it will be included.
Agreed. Someone should just install sim-icq and live in it for a while, then go and implement that for Kopete.
As I said above.. Notifications *do* happen when the window is selected. There is a KNotify event that happens on every new message *period*. All you have to do is go configure it to show a passive popup window / flash the taskbar. You can even configure it to send dcop commands to KDesktop to flash your wallpaper if you want! Point is, KNotify can do anything. For reference, the event is "An incoming message has been received" Note that the systray animation is *not* part of this. The systray only happens on a new message to an unopened window. As it should, this is how all the tabbed clients I know of behave.( namely, Gaim and Trillian - SIM doesn't even have tabs, at least not that I have seen, so you're comparison is off base )
>Notifications *do* happen when the window is selected. There is a KNotify event that > happens on every new message *period*. All you have to do is go configure it to show a > passive popup window / flash the taskbar. No, sorry but I believe that you still dont get the point. 1) flasing taskbar isnt spefic to anything, and confusing (not to mention it's broken when task grouping is enabled, even if that's a kicker bug, and it doesnt seem to work in slicker.. not to mention that the taskbar is optional so you cant assume everyone uses it) 2) it may be exactly the same for an user if the chat window is open or closed if you cant see it, it is even likely that if he/she doesnt even know if the window is open or not after a while of not using it, so the behavior -just like with the traybar- should work for both cases. 3) tray icon flashing is the best way to sightly notify the user that there are messages pending in any desktop without distracting him/her. Popups cover a part of the screen and sound isnt allways available nor it can be heard if you are away, not to mention that i cant find a use for dcop that isnt hackish. 4) this behavior has been there since the first icq and aim days, tabbed or not, and i dont see why it cant be honored. 5) you should read to the post above yours, honestly, SIM has been tabbed since ever and it supports this behavior nicely and consistently, so does gaim (I have just tried it) 6) I have read this request countles times in the bug reports by several users, what is wrong about adding it being quite a popular feature request? or at least EVEN adding it an option? I can code it myself if necesary! So i am reopening this again unless I read something more convincing.
Ok I did some research... Installed trillian on a Windows computer, as far as I can see, kopete takes trillian behavior, so it's good to compare this option. Amazingly, even if both work the same, trillian makes a lot more sense, because the option is called: "on creation of a window, notify me via the systray" which is what actually happens in both, while on kopete it is called: "notifications: flash the system tray on new messages" which is not what actually happens so then, conceptually it could be fair to have two tray icon notifications, which could be even more clear: 1-On creation of a window (the current one in kopete) 2-On new messages (one that can be added) On a side note, I also installed ICQ and AIM and both still follow the behavior I previously described, when windows are minimized or in another desktop (using nvidia desktop switcher for windows) So then again, I ask to include this behavior, the reasons: 1) It is a simple and useful feature, simpler and more to the point than anything else available on kopete right now, with no existing features making it redundant. 2) even if it was redundant, it is a familiar behavior that exists in several other applications, so it can just be honored. 3) It has been requested by several users already on this bugzilla 4) and, to avoid wasting anyones time, I can program it myself if accepted Juan Linietsky
> SIM doesn't even have tabs, at least not that I have seen, Just for how much you know about sim. So good for Kopete developers. I'm really intrigued, what design decision keeps you from implementing a proper and DEMANDED ui feature?
On March 8, 2004 06:48 pm, Juan Linietsky wrote: > No, sorry but I believe that you still dont get the point. > 1) flasing taskbar isnt spefic to anything, and confusing ? It flashes the window where the message was. How is that not specific enough? And how would flashing the system tray be *more* specific? The system tray doesn't say *anything*, there is no way to tell what window is flashing it before clicking the tray. > (not to mention it's broken when task grouping is enabled, even if that's a kicker bug, Which should be reported to Kicker > and it doesnt seem to work in slicker. Slicker isn't even a real KDE app... it's not even part of KDE as it was rejected by the usability team and pretty much everyone else. Not of concern to me.. > . not to mention that the taskbar is optional so you cant assume everyone uses it) Which is why there are many other notifications like sounds and passive popups and even EXEC to run your own commands. > 2) it may be exactly the same for an user if the chat window is open or closed if you cant see it > it is even likely that if he/she doesnt even know if the window is open or not after a while of not using it, > so the behavior -just like with the traybar- should work for both cases. I don't understand this comment... > nor it can be heard if you are away, Enable events while away? > not to mention that i cant find a use for dcop that isnt hackish. DCOP is a hack now? It's a core component of all KDE programs. > 4) this behavior has been there since the first icq and aim days, tabbed or not, and i dont see why it cant be honored. No, it hasn't! If there is a chat open with someone, the tray does *not* flash in windows ICQ, it never has, and rightfully so, as such behavior would be extremely annoying. > 6) I have read this request countles times in the bug reports by several users, what is wrong about adding it being quite a popular feature request? > or at least EVEN adding it an option? I can code it myself if necesary! Because it would either be something incredibly annoying to everyone who doesn't want their tray icon blinking all the time, or it would be another option where we already have too many ( notifications ). If you're going to insist on continuing to re-open this then I will mark it as a wish since it is certainly not a bug.
Ok, here I go again > Which is why there are many other notifications like sounds and passive popups and even EXEC to run your own commands. this is the same as the dcop thing, it's hackish because it is a big workaround for a very simple behavior which can be implemented in an easier way by flashing the system tray! and also is there an event of "user read that message?" because if not, any kind of notification that one does using dcop or wathever is useless.. because there is no way to stop the notification.. OR if you make it stop automatically, you can miss it if you are away.. and NO, notifications on away dont work, dont even consider them because if i am talking to someone and then stand up and go take a dump, any sound or popup will be gone when i'm back, and you cant expect me to set the thing to away by hand each time I stand up because it means complicating things... so "enable events while away" isnt very useful anyway. >No, it hasn't! If there is a chat open with someone, the tray does *not* flash in windows > ICQ, it never has, and rightfully so, as such behavior would be extremely annoying. What?? I tried this an hour ago and it works this way! I invite you to do it yourself if you have a windows machine! >Because it would either be something incredibly annoying to everyone who doesn't want >their tray icon blinking all the time, or it would be another option where we already have >too many ( notifications ). Really who are you to decide that it is annoying? cant you understand that other people likes this? that it is a behavior that comes enabled in lots of applications and nobody complains? I actually agree on moving it to a wish, but what matters the most to me is this being accepted, I dont care implementing it myself. Juan Linietsky
On March 8, 2004 08:49 pm, Juan Linietsky wrote: > this is the same as the dcop thing, it's hackish because it is a big workaround for a very simple behavior which can be implemented in an easier way by flashing the system > tray! and also is there an event of "user read that message?" because if not, any kind of notification that one does using dcop or wathever is useless.. because there is no way to stop the notification.. OR if you make it stop automatically, you can miss it if you are away.. > and NO, notifications on away dont work, dont even consider them because if i am talking to someone and then stand up and go take a dump, any sound or popup will be gone when i'm back, and you cant expect me to set the thing to away by hand each time I stand up because it means complicating things... so "enable events while away" isnt very useful anyway. Every single thing here just leads more and more towards the message bubble. If you want a queued persistant system like this why aren't you using the bubble? Why so insistant on the tray which doesn't give any indication of what user the message is from, and can only ever mean one thing at a time? The bubble is queued, it will show you *all* the messages that arrived while away. > What?? I tried this an hour ago and it works this way! I invite you to do it yourself if you have a windows machine! I have it open right now? I wonder if you are realizing what you are saying? You're basically saying that since the icon flashes even when a window is open, whenever you get a message the icon would basically flash forever until you clicked it away. This is certainly *not* what I am seeing.
Oh I believe that there is a sort of misunderstanding here.. The buble is actually very annoying, because it takes space on the screen, one just wants a simple way to know that there are messages pending, that's all about it.. And no, please re-read the logic above, I assume i was not clear enough the idea is very simple.. the tray icon should flash until you read the message, and if you click on it, it takes you directly to the first message on the queue. Now, what I am arguing is that it's not enough to flash it when the chat window is not open, I am saying that it should flash when the chat window is: 1) not open (doesnt exit) 2) it is open but it's covered by other windows, or in another desktop 3) the tab with user that sent the message is hidden right now it only does on 1), but i'm arguing that it should on all. Of course, if you go and focus the chat window by yourself, and select the window or tab, or basically, just do anything that makes the window visible... the tray bar should stop flashing... so the logic is simple: 1) while the message is not visible by any reason, flash the tray icon 2) if the message is visible, remove the event from the queue, and if there are no more events pending, stop flashing the tray icon. 3) as a helper, clicking the tray icon when flashing takes you to the first message on the queue by focusing the window.. this of couse causes 2) to happen. ICQ does have this behavior, of course if you have window raising on messages enabled by default you will never see it flashing, but if not, you will notice how even if you have the window open, but unfocused, the tray icon will flash until you click it or focus the window. Same applies for the others... This is different than the existing kopete notifications, and i'll list why one by one, comparing them to just flashing the tray icon with this behavior *passive notifications: they take part of the screen, can be distracting, and fade out after some seconds, so if you are looking somewhere else at the moment, or you just left the computer, you miss it *sound: not allways have it available, and also is useles if you just left the computer *bubbles: are too invasive, distracting *taskbar entry flashing: useless if the windows is in another desktop and you dont see windows from all desktops. It is also not as "specific" as just clicking the tray icon and being sent to the first message in queue *away notifications: useless if you use a notification that displays for a limited time and you just left the computer *execute a program: this is not useful because you need to clear the status of whathever you do when you read the message *auto raise window: this is too invasive So as you see, there is nothing as simple as the tray bar icon flashing, it just tells you of pending unread messages, doesnt take an extra area of your screen, doesnt fade away after a while and doesnt interrupt your work. No other notification in kopete meets all this together. The current ones may solve a problem but introduce other. I hope to have been more clear this time.
Could everybody please calm down? It's a minor change in the behavior that enhances an already existing feature. It does not cripple anything or disables something that used to be there before. AFAIK Juan proposed to write a patch, so why not have him submit it, review it and just commit it if it's good. All this closing and reopening is rather childish.
I haven't read the whole topic. But i realy think that this feature could be added. If Juan send us a patch, and if it's correctly wrote, i think i'll vote for adding it ; because i think a notification more can't hurt, specialy if it configurable.
*** Bug 60889 has been marked as a duplicate of this bug. ***
I have the same request. All that still keeps me from using Kopete is the fact that new messages arriving in an unfocused chat window are not notified using the tray icon, so I easily miss them. It is not acceptable to have to put the chat window in the foreground to check the arrival of new messages, and I don't want to use KNotify because it can't distinguish between Kopete having focus or not. Of course, if I have the chatwindow open and focused, meaning that I am probably reading the message, I _don't_ want to get notified at all. Would be cool if one could even disable sounds if the chatwindow is focused, by the way, as Sim and GAIM offer it. This can't be a complicated feature and could be configurable as optional, so everybody would be happy. I don't see why there is such opposition against this enhancement, which certainly would not hurt Kopete's usability!
On June 30, 2004 09:34 am, sputnick@gmx.net wrote: > and I don't want to use KNotify because it can't distinguish between > Kopete having focus or not This is not true. Knotify can indeed tell, for certain events. If you have "Flash the taskbar" turned on (it is on by default), KNotify will flash the taskbar of a window with a new message *only* if it was unfocused.
Flashing the taskbar is, however, not an acceptable notification method, at least not for me and others, because a) you can't see it on other desktops, b) people may hide the taskbar, and c) at most times there are more than one taskbar items flashing, so it's still easy to overlook. Moreover, and that's the most important point, I'd like to have a consistent notification behavior. One look to the systray, and I see if I have received new messages. A click on the blinking tray icon, and the new message pops up, regardless if I had a chatwindow before which just has to go into the foreground, or if a new message window has to be opened. This is a consistent, logical behavior and this is how it works in licq, Sim, Gaim, and Windows ICQ (and has worked like that for ages). It's just so much nicer to not need to distinguish between having a hidden chatwindow and not having a chatwindow at all, and to not have to look in more than one place to see this. Moreover, this is probably not too hard to implement and can be easily configurable in the options, so I simply see no reason not to do that. Otherwise, Kopete is a great messenger and leaves everything else in the dust. With this feature enhancement, it is going to be perfect.
On June 30, 2004 01:40 pm, sputnick@gmx.net wrote: > This is a consistent, logical behavior and this is how it works in licq, > Sim, Gaim, and Windows ICQ (and has worked like that for ages). This isn't true. I don't know about Sim or Gaim since I have never used them except for testing things, but both Windows ICQ and Windows MSN it does not behave this way. If you have a window open and are chatting with "Foo", and switch away to an IE window, and "Foo" sends another message, the tray icon does *not* flash. The taskbar entry does, but the tray does not. The tray only flashes if you do not have a conversation window open to that person.
Oh geez!! not this mess again! Jason, I ask you to please either understand the following or stop commenting, because you dont seem to be able to grasp what is going on.. so for the tenth time, I'm going to try to make it clear. -Taskbar notifications are **NOT ENOUGH** because **LINUX HAS MULTIPLE DESKTOPS** and **YOU DONT SEE NOTIFICATIONS FROM OTHER DESKTOPS** Windows only has **ONE DESKTOP** so comparing it is **NOT FAIR**. Maybe you have the option to see windows from all desktops enabled, well others dont use this. -KDE bubble notifications are **ANNOYING** and **INVASIVE** for many of us -And most important of all, this is **NOT** a matter of **MISSING FUNCTIONALITY**, this is just a matter of **USABILITY**, where points of view are **SUBJECTIVE** and **YOU CANT EXPECT EVERYONE TO FEEL THE SAME WAY AS YOU REGARDING TO AN INTERFACE** the simple fact that so much people **WANTS THIS FEATURE** should tell **YOU AND THE REST OF THE DEVELOPERS SOMETHING** but I'm still amazed that it doesnt. On a side note, I did check the whole kopete source code and learnt it. It's really nicely done and easy to understand, but unfortunately adding this is not as easy as it seems, because kopete destroys the message object as soon as it is displayed. I'd rather an experienced kopete developer to understand and add this functionality than doing it myself because this possibly requieres either a bit of design changes or adding a dirty hack, both of which would probably rejected if I make a patch. Cheers! and sorry for being a bit rude, but at this point it pisses me off that kopete developers dont take so much people in mind. I mantain several other pretty popular apps and when users or other developers want to make changes like this, I either add them myself or tell them how i'd like them to be done.. I couldnt get any of this forward at the time from the kopete developers, they just told me "do it and we'll see". This is why I'm still using SIM as my messenger, and i'm starting to feel that i'd rather contribute time and code to improve that rather than dealing with kopete..
On June 30, 2004 02:39 pm, Juan Linietsky wrote: > -Taskbar notifications are **NOT ENOUGH** because **LINUX HAS MULTIPLE > DESKTOPS** ... Please calm down! I was not saying your idea was wrong. All I said was that your statement was wrong, and this is *NOT* the way ICQ and MSN behave even though you said so! > On a side note, I did check the whole kopete source code and learnt it. > It's really nicely done and easy to understand, but unfortunately adding > this is not as easy as it seems, because kopete destroys the message object > as soon as it is displayed. That is not why it is difficult to implement, and it essentially has no bearing on it. Making the system tray flash when the window is not focused is simple, it is pretty much a one line code-change - a no-brainer. The question is if this is desired, and IMO this is not at all clear. As I showed above, client behaviour on this is not at all consistant. Just because Gaim does it one way does not make it the right way, and just because you want it one way does not make it the right way, no more than just because I want it one way makes it right. The whole issue needs discussion among all the developers. From viewing the thread, Martijn also agreed that it needs lots of thinking before any changes to our notifications are made.
So, if it's that easy to implement, why don't you just offer the option? Just have a checkbox "Tray notification for open chat windows" and then both groups of users can have what they want. Turn it off by default, and nobody not interested will even notice the new option, and for those people there will be no changes to the notifications. And people like me who like a behavior consistent with Sim and Gaim (hm, and I am still fairly certain that last time I checked my Windows ICQ did it too, but I won't boot Windows now to doublecheck, as it is not really important...) can simply enable the feature and be happy too.
> That is not why it is difficult to implement, and it essentially has no > bearing on it. Making the system tray flash when the window is not focused is > simple, it is pretty much a one line code-change - a no-brainer. No, this is not a one liner at all, or at least it wasnt when I last looked at the source code.. because basically you need to implement a pending unread messages queue somewhere, so each time you click on the system tray icon, it takes you to the window/tab of the next unread message in the queue. moreover this needs to be done cosistent with the existing notifications because it would make no difference wether a chat window is open or not. Clicking on the tray bar will open a chat window or tab to the user if it doesnt exist, and if it does already then it will refocus the existing window/tab of the message. You also need to take in consideration that if instead of clicking the tray icon, the user focuses the window/tab of an unread message by himself then the messages displayed there must be removed from the queue. Once the queue is empty, the system tray icon stops flashing. As you see this behavior is probably more complicated than what you had in mind. To me it is a LOT more consistent than having 3 kind of different notifications to make sure you read the message, as it is now in kopete. This one works for all cases. Cheers!
On June 30, 2004 03:23 pm, Juan Linietsky wrote: > No, this is not a one liner at all, or at least it wasnt when I last looked > at the source code.. because basically you need to implement a pending > unread messages queue somewhere, You mean like the mesage queue that is enabled when you check the box that says "Use the message queue"??? :P We already have this, how do you think the bubble notification works?
On June 30, 2004 03:02 pm, sputnick@gmx.net wrote: > So, if it's that easy to implement, why don't you just offer the option? > Just have a checkbox "Tray notification for open chat windows" Because we already have too many options. Kopete is option overloaded, and it is so complex that we cannot add an option for every GUI wish. Perhaps a hidden KConfig option would be an answer, like our hidden option to turn on hover close buttons on the tabs. Regardless, you still have to choose the default setting.
Em Quarta, 30 de Junho de 2004 19:33, o Jason Keirstead escreveu: > Because we already have too many options. Kopete is option overloaded, and > it is so complex that we cannot add an option for every GUI wish. you sound like the gnome dudes ... of course not to every gui wish ... but kopete is not that option overloaded !! also , i would like to use it if its implemented ... and i guess other ppl would too !
Also do not forget, with the release of Zacks KXConfig, you'll be able to set all those "hidden" options through a nice interface. Like the windows registry editor, or GCnof, except way better since the options will have nice description fields. And it will be network-transparant!
On June 30, 2004 03:46 pm, Jason Keirstead wrote: Er sorry, thats KConfEdit.
this discussion is just sick, so many useless options :(
> You mean like the mesage queue that is enabled when you check the box that > says "Use the message queue"??? :P > We already have this, how do you think the bubble notification works? Last time I checked, the messages are removed from the queue once that they are delivered, the point is that they should be removed once they are read. In any case, lets assume it's not difficult to do technically. This is an option several users want and your point of view is highly gnome-ish. KDE has feature overloads everwhere and I dont think there is anything wrong with that, since it's allways been that way. Several users want to manage their messaging this way and I dont see adding a simple extra checkbox being a problem.. as several other messenger apps use the same approach. We are not discussing any fancy patch to make windows dance or anything, this is a highly requested feature and the fact that it is redundant for you doesnt mean that it is for others.
> this discussion is just sick, so many useless options :( Yes, for microsoft tabs in iexplorer are useless, as well as multiple desktops, why should they implement them? Oh yeah, translucency in X is also useless.. yet so many users want such features.. they are stupid, and we the nazi developers must educate them that there can be only one way of doing things and useless features shall not be tolerated
On June 30, 2004 04:29 pm, Juan Linietsky wrote: > Last time I checked, the messages are removed from the queue once that they > are delivered, the point is that they should be removed once they are read. I don't know when you last checked, but Kopete has had a message queue since before version 0.6. If you have the bubble enabled, the messages are queued until you click "View Message", then they are all delivered. If you click "Ignore", they are dropped. And I think it also behaves the same way if you have the flash system tray option turned on.
Em Quarta, 30 de Junho de 2004 19:57, o Stefan Gehn escreveu: > this discussion is just sick, so many useless options :( useless ?? maybe only to you .... every option for you is useless ... you just expect for everyone to use kopete the same way you do
On June 30, 2004 08:40 pm, Iori Yagami wrote: > useless ?? maybe only to you .... But Stefan has a valid point. Every option is usefull to 20% of people and useless to 80% of others. This is why less options is always good, where possible.
I really don't care how I can enable this feature, as long at it is possible at all ;) If it requires editing "hidden" options, that's fine with me. It would just increase Kopete's usability for me _personally_ enough to make that my default messenger. As fot the number of options, having too many options does not hurt as much as having too few options. If people are happy with the default settings, they can easily ignore the options. If people are missing one option or another, they can't do anything to change that. Also, it is always possible to hide stuff like that behind a "Advanced" button. I really can't see how this can disturb or hurt anybody. I always found the configurability one of the major advantages of KDE over Gnome, and of Linux over Windows. Easy is not always good. Reasonable default settings and hidden options are cool for newbies, but the pros should still have the possibility to tweak their system as much as they want. This is exactly what Linux and most KDE programs can give me.
On Mittwoch Juni 30 2004 22:50, sputnick@gmx.net wrote: > As for the number of options, having too many options does not hurt as much > as having too few options. If people are happy with the default settings, No, no, no, _both_ ways are wrong. I have tried enough applications that got uninstalled five minutes after I started them just because their mass of options, bells and whistles. I don't want an application to make me change 2563743 different options before I can use it. The other extreme is apps that I don't feel comfortable with and which I cannot make behave like I want. > they can easily ignore the options. The visual appearance when you open a preferences dialog for the first time _does_ make a difference! > If people are missing one option or > another, they can't do anything to change that. Also, it is always possible > to hide stuff like that behind a "Advanced" button. I really can't see how > this can disturb or hurt anybody. Having to click on "Advanced" buttons all the time is not an option either. > I always found the configurability one of the major advantages of KDE over > Gnome, and of Linux over Windows. Easy is not always good. Reasonable > default settings and hidden options are cool for newbies, but the pros > should still have the possibility to tweak their system as much as they > want. This is exactly what Linux and most KDE programs can give me. Look at fvwm2 if you want to see a bad example of overconfigurability (or however you want to name it). You can spend weeks on your fvwmrc and still it's not perfect yet. And I really doubt having a gui for such a beast would make it any better for anybody. Making _everything_ configurable might look appealing at first but new users will sooner or later end up searching options and getting lost in the djungle of checkboxes. And to be honest, I don't like our configuration dialog anymore either. Too many color options, the separation of appearance and behaviour might be logical but doesn't follow my editing-flow (i.e. I have to jump between the two pages) and still the dialog became way too huge (remember, we once did this split-up to make the size behave again). Bye, Stefan aka mETz
Em Quinta, 1 de Julho de 2004 09:27, o Stefan Gehn escreveu: > Having to click on "Advanced" buttons all the time is not an option either. if the option is useless as you say , you dont have to click on advanced all the time. you have to see that alot of ppl use kopete diferently ( i myself use it for all protocols , yes , irc even , with no taskbar on desktop and alot of virtual desktops , you , i am sure , use it very diferently than me ) either way , this discussion is getting rather large.
On Thursday 01 July 2004 10:27, Stefan Gehn wrote: > No, no, no, _both_ ways are wrong. I have tried enough applications that > got uninstalled five minutes after I started them just because their mass > of options, bells and whistles. I don't want an application to make me > change 2563743 different options before I can use it. That's why you have reasonable default options that work for the majority of the users. Those users don't have to change 2563743 different options to work with the program. On the other hand, people not happy with the default settings can always change them. > The other extreme is apps that I don't feel comfortable with and which I > cannot make behave like I want. Exactly. For me that's the case with the current version of Kopete. And apparently I am not the only one. > > they can easily ignore the options. > > The visual appearance when you open a preferences dialog for the first time > _does_ make a difference! Yes. Put the basic options on the main page and hide the advanced stuff somwehere else, so people don't see them when they open the dialog. > > If people are missing one option or > > another, they can't do anything to change that. Also, it is always > > possible to hide stuff like that behind a "Advanced" button. I really > > can't see how this can disturb or hurt anybody. > > Having to click on "Advanced" buttons all the time is not an option either. Usually I do have to click on that exactly once. It's not like I am reconfiguring my application every day. Once it works as expected, I leave the preferences alone. And of course you can't have everything at the same time. You want an application that works right out of the box for everybody, that behaves exactly like everybody wants, that has a clean preferences dialog, but still features all needed preference settings without hiding part of them somewhere. You can do that for an application you write for yourself, because you can write it your way. But you will never be able to do that for an application that's widely used by people, because people usually don't agree on preferences and have different usage patterns. > > I always found the configurability one of the major advantages of KDE > > over Gnome, and of Linux over Windows. Easy is not always good. > > Reasonable default settings and hidden options are cool for newbies, but > > the pros should still have the possibility to tweak their system as much > > as they want. This is exactly what Linux and most KDE programs can give > > me. > > Look at fvwm2 if you want to see a bad example of overconfigurability (or > however you want to name it). You can spend weeks on your fvwmrc and still > it's not perfect yet. And I really doubt having a gui for such a beast > would make it any better for anybody. fvwm2 does not come with reasonable default settings. KDE does, Kopete does, and both require only minor tweaks to exactly fit my needs. Bad thing that Kopete does not offer me possibility of tweaking it like that. Besides, offering a behavior that is consistent with most other messengers is nothing I'd call "overconfigurability". Nobody expects you to offer a config file that lets me place every control where I want it. -- Manuel
I wonder if there has been any progress made in this direction, or if there is any hope of getting a message notification behavior that is actually useful for me and many others? At least some hidden option in some configuration file, if you don't want to overfill options dialogs? If it's only some lines of code to change... Meanwhile I have switched to Gaim, because it has a flashing systray icon if new messages arrive, and (another nice feature) it is only one click to mute all sounds if you are, for example, listening to music and don't want to get the ICQ noises. Other than that, Gaim is sometime a pain in the a.., and I'd rather like Kopete to get useable for me. After all, my desktop is KDE, not Gnome. -- Manuel
Is anyone working on this? I tried what I thought was the one-line fix alluded to above (remove the check for view(manager, outgoingMessage)->isVisible() in KopeteViewManager::messageAppended()), but while that does make the system tray icon flash, it also makes Kopete crash after receiving three messages. I'll see if I can find the time to understand more of the code base and figure out why later. This is the only thing that keeps me from using Kopete at the moment. But until it is fixed, I'm stuck with using LICQ, which, while it has several major flaws, at least supports my window managing habits (like SIM and Miranda did when I used them).
*** This bug has been confirmed by popular vote. ***
Created attachment 8436 [details] Patch for the version included in kdenetwork 3.3.1 This is a quick, almost not at all tested patch that, when applied to kdenetwork 3.3.1, makes Kopete blink its systray icon on all incoming messages, even when there is already a chat window open. It doesn't allow user configuration, but since the notification setting says "An incoming message has been received", I think this is the logical behaviour. I don't expect this patch to be accepted. It's made against a release instead of CVS HEAD, and probably doesn't fit the KDE coding standards at all (my previous KDE experience is limited to "Hello world"). But it works for me (and allows me to finally throw LICQ out and switch to Kopete), and perhaps will serve as a base for someone else to do it right, since there are obviously more people than me who want this feature.
I agree with Juan. Here are my points: 1) Passive popups don't work because they (afaik) dismiss themselves. That means if I'm not at my computer at the time of their appearance, I'll miss them. That and they are intrusive and annoying...=) 2) (In regards to using knotify) "You can do *anything you want*." Yeah, except flash the system tray icon until the window containing the new message has focus. Heck, maybe we *can* do that with knotify and dcop, but like Juan said, doing that is overly complex for some feature that could be implemented in code rather easily. Also, newbies prolly won't know how to use dcop like that. 3) I don't really care what other IM clients do. Kopete is what I (want to) use and this is a feature I want. I'm not demanding it, I'm asking for it. Btw, in case anyone has forgotten, the feature I want is for the Kopete system tray icon to flash until _all_ windows with new messages have gotten input focus (or brought to the front or whatever). Also, double clicking the flashing system tray icon should bring to front/focus the window with the first new message. The motive for this is because I use multiple desktops with the "do not show taskbar entries from other desktops" option checked. Passive windows and sounds are deficient because they can occur while I'm away from my computer (which happens often).
On Monday 24 January 2005 12:48 pm, Christopher J.Bottaro wrote: > The motive for this is because I use multiple desktops with the "do not > show taskbar entries from other desktops" option checked. Passive windows > and sounds are deficient because they can occur while I'm away from my > computer (which happens often). So why don't you just use KNotify to run a script that checks via dcop if your screensaver is active, if it is, then use KDialog to issue an alert. Took me like 2 mins to write: #!/bin/sh MSG=$1 CONTACT=${MSG#incoming message from} if [ `dcop kdesktop KScreensaverIface isEnabled` == "false" ]; then msg="%e"; kdialog --title "Kopete - New Message" --yesno "$MSG \nDo you want to respond?"; if [ "?" == "0" ]; then dcop kopete KopeteIface messageContact `kdialog --title "Kopete-New message" --inputbox "Enter your message:" "Hi, $CONTACT"` \; fi fi
While good perhaps while away from the system and the screensaver is running, this does not address the other situations mentioned in an elegant way. As mentioned many times, in a multi-desktop setup, your Kopete window could well be on another desktop. If the screensaver is not active, this solution will not work. If you strip out the screensaver checking part, then you constantly have new windows poping up for new messages, and possibly stealing focus. Kopete is different from most other desktop applications. It is something that may require near "real time" (used very loosely) notication that something has happened to it, regardless of what desktop it is on, or what items are available on your taskbar. The only item guaranteed to be on all screens (if the option is enabled) is the system tray icon. I have also recently found out this problem is worse than I originally thought. I have taken a liking to chatting in a tabbed window. Occasionally I get more tabs than can fit in the window. In this situation, even if Kopete is on my desktop I don't get notified of new messages all the time. The tab a new message comes in on could be hidden off the side. If Kopete has focus when this new message comes in, there is no notification anywhere, forcing me to constantly check all my open tabs. Kmail already does something similar for new e-mail, so this is not a feature request unique to Kopete. Kmail will change the system tray icon to show you new messages, and will even show the system tray icononly when new messages are waiting. Even if you wanted to make this work like KMail then, it would maintain consistency. That is, on the Kopete icon, show the number of unread new messages waiting, with some kind of shortcut on the right-click menu to view the next unready message, or similar to KMail again, a "New messages" menu on the right-click menu that shows you a list of people who sent you a new message to select from. From that point of view, you are using existing base application KDE, so consistency and UI arguments should be satisfied.
I have been using kopete all the time, and now that I have upgraded to trunk (to get msn working) flashing the task bar icon doesn't work any more. Can someone explain why this behaviour has changed? is there a patch to get it back to how it was before? The current behaviour makes using kopete very inconvenient as you don't get any notification when your message window is open but behind another window.
SVN commit 439827 by jritzerfeld: Added 6 options to "Configure Kopete..."->"Behavior"->"General": [Notifications] [Show a bubble on new message] Button "Ignore" closes chat view [Flash the system tray on new messages] Flash on unread messages Flash only on highlighted unread messages in group chats Flash only on unread messages in chat windows on another desktop Left mouse click on system tray opens message Opening message sets current desktop to chat view's FEATURE: 65019 M +4 -1 kopete/chatwindow/chatview.cpp M +24 -0 kopete/config/behavior/behaviorconfig.cpp M +185 -3 kopete/config/behavior/behaviorconfig_general.ui M +2 -1 kopete/systemtray.cpp M +3 -1 libkopete/kopetemessageevent.cpp M +42 -0 libkopete/private/kopeteprefs.cpp M +18 -0 libkopete/private/kopeteprefs.h M +36 -9 libkopete/private/kopeteviewmanager.cpp M +1 -1 libkopete/private/kopeteviewmanager.h
SVN commit 439828 by jritzerfeld: Backward port: Added 6 options to "Configure Kopete..."->"Behavior"->"General": [Notifications] [Show a bubble on new message] Button "Ignore" closes chat view [Flash the system tray on new messages] Flash on unread messages Flash only on highlighted unread messages in group chats Flash only on unread messages in chat windows on another desktop Left mouse click on system tray opens message Opening message sets current desktop to chat view's CCBUG: 65019 M +4 -1 kopete/chatwindow/chatview.cpp M +24 -0 kopete/config/behavior/behaviorconfig.cpp M +185 -3 kopete/config/behavior/behaviorconfig_general.ui M +2 -1 kopete/systemtray.cpp M +3 -1 libkopete/kopetemessageevent.cpp M +42 -0 libkopete/private/kopeteprefs.cpp M +18 -0 libkopete/private/kopeteprefs.h M +36 -9 libkopete/private/kopeteviewmanager.cpp M +1 -1 libkopete/private/kopeteviewmanager.h
*** Bug 102168 has been marked as a duplicate of this bug. ***
SVN commit 444316 by jritzerfeld: Renamed and reordered some options in "Configure Kopete..."->"Behavior"->"General" tab to reflect the dependency between queueing and trayflash/bubble: [Notifications] Queue unread messages (was: Flash on unread messages) Queue only highlighted unread messages in group chats (was: Flash only on highlighted unread messages in group chats) Queue only unread messages in chats on another desktop (was: Flash only on unread messages in chat windows on another desktop) Show a bubble on queued message (was: Show a bubble on new message) Button "Ignore" closes chatwindow (was: Button "Ignore" closes chat view) Flash the system tray on queued message (was: Flash the system tray on new messages) Left mouse click on system tray opens message Switch to desktop containing chat on opening message (was: Opening message sets current desktop to chat view's) Fixed/added slots that disable options depending on system tray. CCBUG: 65019 M +49 -18 kopete/config/behavior/behaviorconfig.cpp M +3 -0 kopete/config/behavior/behaviorconfig.h M +60 -62 kopete/config/behavior/behaviorconfig_general.ui M +2 -0 libkopete/kopetemessageevent.cpp M +17 -17 libkopete/private/kopeteprefs.cpp M +9 -9 libkopete/private/kopeteprefs.h M +9 -9 libkopete/private/kopeteviewmanager.cpp
SVN commit 444317 by jritzerfeld: Forward port: Renamed and reordered some options in "Configure Kopete..."->"Behavior"->"General" tab to reflect the dependency between queueing and trayflash/bubble: [Notifications] Queue unread messages (was: Flash on unread messages) Queue only highlighted unread messages in group chats (was: Flash only on highlighted unread messages in group chats) Queue only unread messages in chats on another desktop (was: Flash only on unread messages in chat windows on another desktop) Show a bubble on queued message (was: Show a bubble on new message) Button "Ignore" closes chatwindow (was: Button "Ignore" closes chat view) Flash the system tray on queued message (was: Flash the system tray on new messages) Left mouse click on system tray opens message Switch to desktop containing chat on opening message (was: Opening message sets current desktop to chat view's) Fixed/added slots that disable options depending on system tray. CCBUG: 65019 M +49 -18 kopete/config/behavior/behaviorconfig.cpp M +3 -0 kopete/config/behavior/behaviorconfig.h M +60 -62 kopete/config/behavior/behaviorconfig_general.ui M +2 -0 libkopete/kopetemessageevent.cpp M +17 -17 libkopete/private/kopeteprefs.cpp M +9 -9 libkopete/private/kopeteprefs.h M +9 -9 libkopete/private/kopeteviewmanager.cpp
I was just about to file a wishlist entry, for flashing the tray icon on any message, even when there is already an open chat window. Well, then I found this lengthy discussion and found that it's already possible. So I turn this into a usability report. IMHO the wording of the options is a bit unfortunatly choosen. Without reading this discussion I would _never_ have gotten the clue that they might have something to do with my problem (and thus I simply ignored them up to that point). In fact even then it took me some time and reading the associated "what's this" help texts a few times before I understood what they mean. They kind of confuse more than they help. They talk about a strange concept of message queues, incoming messages, new messages, unread messages, queued messages... As a user who is not deeply involved with kopete, this just gives me a big "Huh?! What??" ;) It seems to me that the options are actually not about message queues, at least from the users POV. I mean who cares about a message queue? Shouldn't they always be queued anyway? I mean who wants to loose messages? So let's look at the options. Option "Use message queue": Actually the mouse over help and "what's this" help say different things. So what's actually the point of this option? Is it to _not_ immediately open a message window on incoming messages? Then it should be named like that, e.g. "Automatically open chat window on first message". Or is it about flashing tray icons and bubbles? But they are configured on the "Events" page already. Even more awkward is the 2nd otpion "Queue unread messages". The user has to understand the concept of the message queue first. And then why queue at all? I mean they end up in the open message window anyway? So the whole point of this option seems to be: Flash tray icon on _any_ message i.e. also when there is an open chat window. Then it should be named like that. And probably moved to the Events page. Now that I basically got what I wanted: I would like to disable the bubble for subsequent messages i.e. when the chat window is already open. It's nice and helpful for the first message, as you instantly know who wants something from you, and whether you want to answer immediately or later. But it's pretty intrusive further on, like those passive popups. So IMHO it should default to that: Flashed tray icon and bubble on first message, flashed tray icon only on subsequent messages (i.e. when chat window open)