Version: (using KDE 4.1.1) OS: Linux Installed from: Ubuntu Packages Some years ago a change was made on how the showing of main windows of systray apps is handled. Since then you are taken to the desktop where the main window currently resides. This is *extremly* annoying me since then, as it always disrupts my work flow. You have to orientate yourself where you are and where you came from, go back, and in case you intentionally wanted the window on the original desktop, you have to actively make go there ... Unfortunately it's still the same as of KDE 4.1.1 :( As this change was obviously made on purpose, and there might be a case where this behaviour is wanted, I *never* came across such a case during that time. I *did* come across several cases though, where it makes no sense at all e.g. kopete, amarok, basket, kmix ... These apps live in the systray as they have kind of an omnipresense and are not tied to a particular desktop. (The workaround of making these windows sticky, is not really a solution)
having kontact switch to the current desktop each and every time i clicked on the kmail icon would be painfully annoying. ditto for amarok and basket, btw. amarok is not a transient service for me, though i agree with you on things like kopete. there is a way for applications to have an icon, but not associate it with a window. unfortunately then they have to implement their own window handling. what we need is a way to mark transient services as such in KSystemTrayIcon, perhaps. in any case, this is filed against the wrong component. plasma has no say in this, it's up to kdelibs.
(In reply to comment #1) > having kontact switch to the current desktop each and every time i clicked on > the kmail icon would be painfully annoying. Well, I agree with that. I don't use kontact with systray icons, so I don't have that problem. Of course I know my way of working is not neccessarily representative, but neither is yours :) And from my POV kontact is more or less the only app for which this is true (perhaps kmail or akregator, but I'd say they are usually embedded in kontact anyway) > ditto for amarok and basket, btw. amarok is not a transient service for me, > though i agree with you on things like kopete. Well, for me it is. While I assigned certain desktops to certain activities (e.g. system administrative stuff, internet, work), I can combine listening to music with any of them. And when I'm busy with an activity and my playlist finishes, I like to simply bring up amarok, load something new, close it and continue whatever I did. Same for basket, I use it in combination with any activity: dragging an internet link, look up a shell command, look at notes for a document I'm writing... this is what I meant with "omni presence", for me most systray apps are apps used in combination with everything else. Just like chatting with kopete, I do that no matter what I'm doing and on which desktop I am. > > there is a way for applications to have an icon, but not associate it with a > window. unfortunately then they have to implement their own window handling. > Which unfortunately hasn't happend in the recent years... This change just traded the convenience of one group of users against the one of another group. > what we need is a way to mark transient services as such in KSystemTrayIcon, > perhaps. Why not "fix" kontact and return the rest of the apps to the way they used to work before the change (i.e. come to current desktop)? I think this could be a compromise 90+x percent of users could agree with. > > in any case, this is filed against the wrong component. plasma has no say in > this, it's up to kdelibs. Sorry about that, I didn't know exactly where to put it, so I've chosen the applet :)
i think we can answer the points raised with your own response, actually =) let's see: > Why not "fix" kontact > This change just traded the convenience of one group of users against > the one of another group. .. > I think this could be a compromise 90+x percent of users but: > And from my POV a proper fix is in order, not fixing individual applications one by one with a hack and not flip flopping between one group of users and another.
Yea, my argumentation might be a bit flawed :) However I still see this as an quick and easy compromise until something else has been agreed on and implemented. I don't have any preference how this is eventually solved. I can fully understand, that you want a proper solution and not a workaround. It's just that the current situation is quite annoying and the previous plan of action obviously didn't work out over last years...