Version: unspecified (using KDE 4.7.2) OS: Linux Imho changing the activity automatically just because I'm opening kmail - which I needed before in another activity too - doesn't make much sense to me. I even think it's against the design of KDE's Activities in general: the _content_ of the application should change for another activity, it's not that much about the programs anymore. To summarize: Don't switch automatically to the activity which contains the window, instead add the window to the current activity. (This holds especially for items in the task tray as they are frequently opened on different activities.) If there is some good reason it is designed this way, please at least provide an option to customize this behavior. Reproducible: Always Steps to Reproduce: open kontact in activity "Project 1" and read emails of Project 1. Now switch to activity "Project 2" and open kontact which sits in the task tray to read mails regarding project 2. Actual Results: You're in the activity of the other project now, which is not what you intended: you wanted to work on project 2. Expected Results: You're still in the "Project 2" activity, because that's what you want to do: working on Project 2.
I agree. the reason this happened: it was an easy way of handling taskbar clicks before it defaulted to only-show-this-activity. Also, wants-attention windows shouldn't be added to the current activity. At the time I didn't run into any problems, since I don't use many systray apps. But now I have to use firefox for a project, which has this and many other issues :) What I don't remember is, would it be feasible to solve this without breaking the wants-attention case? (and is anyone ever going to sync up the taskbar contextmenu with the titlebar one?) I'll move this to kwin, since that's where the activate-window code is.
I always forget to change the assignee when changing the component...
> What I don't remember is, would it be feasible to solve this without breaking > the wants-attention case? I image having a notification popup telling you that application xy from activity yz needs your attention. Then you can choose to ignore or to switch to that activity. I don't want to pretend that I'd have any clue about this, but since kwin has already something like focus stealing prevention built in...couldn't someone modify this code to catch the application longing for attention, this way keeping it in its original activity and showing such a notification instead? Just an idea...
that's a nice idea... I don't know how well it would go over if wants-attention apps *stopped* showing up in the taskbar as well... but the wants-attention colouring is so subtle in the default theme anyways, I usually don't notice it... so I'd guess there's a high chance it would be accepted well. :) another thing to consider is, if the user's busy and can't give it attention until 5 minutes later, will the notification hang around? I can't remember how wants-attention is implemented, but I suspect it's merely a flag the window sets and kwin does the rest. :) I'd love to see someone try out this idea.
> I don't know how well it would go over if wants-attention apps *stopped* > showing up in the taskbar as well... but the wants-attention colouring is so > subtle in the default theme anyways, I usually don't notice it... so I'd guess > there's a high chance it would be accepted well. :) In my opinion this could even be adopted if the application wanting attention is in the current activity. I don't notice the color differences either. Due to litte "bugs" like when you move with your cursor over a task bar entry it starts to glow but it won't stop until you open the application even if you move the cursor away again, I have stopped looking at the different colors and glowing effects of the task bar :-) > another thing to consider is, if the user's busy and can't give it attention > until 5 minutes later, will the notification hang around? I think most of the time is doesn't matter if you forget about the notification and switch to the application much later. However, it's important to handle the notifications properly on shutdown, like saving an unsaved document before closing the editor and so on. I must admit I'm not aware how this is currently handled.
a) why does a window from another activity show up in the taskbar? (or are we talking SNI here?) b) triggering an (KUinque) application which is on another actity should drag it to the current activity, right? => the activity implemetnation in kwin is probably flawed - does it react on _KDE_NET_WM_ACTIVITIES changes? (i didn't find anything like changeActivity in events.cpp / Client::propertyNotifyEvent or the WinInfo class (which however reimplements NetWM and activities aren't in NetWM anyway) If it would, the taskbar or application could just set the property and kwin would place the window there. Is this anything near the issue at all? ;-)
(In reply to comment #6) > a) why does a window from another activity show up in the taskbar? (or are we > talking SNI here?) What is SNI? > b) triggering an (KUinque) application which is on another actity should drag > it to the current activity, right? Unfortunately I don't know what a KUnique application is, but if that's an application with only one allowed instance, then consider Kate as an example. Then it would not be dragged but assigned to the current activity additionally. Consider Kate with only one allowed instance. You're working at project 1. You go to activity 'project 2' and open a textfile. It will be opened in kate. What you want: have Kate on both activities now; ideally kate would only display the files belonging to the current activity (afaik the concept of activities has originally been exactly this behaviour -- having the application adapt to the context). What you don't want is a) to have your activity changed to the one where kate is already open or b) kate is now only on the 'project 2' activity, but vanished from the 'project 1' activity where you probably still need it. But maybe I just got you wrong :) > => the activity implemetnation in kwin is probably flawed - does it react on > _KDE_NET_WM_ACTIVITIES changes? (i didn't find anything like changeActivity in > events.cpp / Client::propertyNotifyEvent or the WinInfo class (which however > reimplements NetWM and activities aren't in NetWM anyway) > > If it would, the taskbar or application could just set the property and kwin > would place the window there. > > Is this anything near the issue at all? ;-) I'm not a KDE hacker so I don't really know what you're talking about so I can't tell :D
(In reply to comment #7) > What is SNI? What the systray used to be =) > Unfortunately I don't know what a KUnique application is, but if that's an > application with only one allowed instance, then consider Kate as an example. Yes, kate however (as some others) can still run in multiple instances (but by default would by no do not) > Then it would not be dragged but assigned to the current activity additionally. important behavioural but technically a minor detail - the property apparetly has a whole list of activities. > I'm not a KDE hacker so I don't really know what you're talking about so I > can't tell :D The question pointed Chani :)
a) either it wants attention (which as discussed here would be better as a notification) or the user configured a taskbar to show all activities (I don't know if anyone actually does this, besides me when debugging activities) b) what kevin said, add to activity. :) as for implementation... there was one thing I forgot about until after freeze, that had to do with setting activities... but, I think it was some api thing, not direct reading of x window properties.... hmm... go go gadget kate sessions! ;) kdelibs/kdeui/windowmanagement/netwm.cpp:4327 seems to react to changes in the property, is that what you meant? haha, svn log actually got me the commit I'm thinking of... r1195560. netwm.cpp has a function to return activities() but no setter. it needs something like NETWinInfo::setDesktop - but that function's not trivial enough for me to throw together a foolproof patch, and I really should be doing homework. :(
(In reply to comment #9) > kdelibs/kdeui/windowmanagement/netwm.cpp:4327 seems to react to changes in the > property, is that what you meant? No, that only means that NETWinInfo2 can read that property. Actually I was looking for the "else if (e->atom == atoms->activities) checkActivities();" lines in events.cpp (gee, my sisters flu has apparently hit me worse than i thought), so it's actually there, the clients only need to set it (the KWindowSystem part) Now, that's quite unfortunate, because while the code isn't that much of a deal iirc kdelibs is frozen until the framesworks thing replaced it :-( So applications (SNI? The Taskbar?) will have to go "the hard way", setting the property by hand ("XChangeProperty", not that much of a problem either)
ok, i want to get get rid of this bug a) Please check whether this would likely fall into the categories of bug #242149 b) Do you think it would be reasonable to only change the activity when a client gets activated by the taskbar or a pager, and if it's activated for other reasons, it's simply added to the currently active activity? Thanks for your assistance and sorry that the bug has been hanging around for so long.
(In reply to comment #11) > a) Please check whether this would likely fall into the categories of bug > #242149 I'm not sure that #242149 is the same. There the problems seems to be different: although the window is already assigned to activity 1, restoring it in activity 1 switches to activity 2. This bug, however, refers to the case where opening an application window by clicking on its icon in the system tray switches to the acitivty where that application has been started. > b) Do you think it would be reasonable to only change the activity when a > client gets activated by the taskbar or a pager, and if it's activated for > other reasons, it's simply added to the currently active activity? I'd like to give an example, to illustrate the discussion: 1) KMail runs and is shown on activity A as a window and in the system tray. Now we switch to activity B (the window is not shown anymore but the systray icon is still there). We click on the systray icon. We expect to see KMail's window but instead nothing happens as the window got minimized to systray in activity 1 (which we do not see). We click again. Now we see the window but the activity has been changed from B back to A. I'm not completely sure, but maybe this bug (and also #242149 as a side-effect) could be resolved by assigning windows that "come from" the systray to all activities. In our example, KMail would then also be shown on activity B and clicking on the systray icon would hide and restore it, without switching the activity. As for #242149, the activity switching would probably also not happen for Amarok. To summarize, I'd prefer if activities would get switched automatically as little as possible. As described above, I would even prefer to never switch automatically but instead show a notification in case that attention is needed on another activity. It is hard enough to concentrate on one activity anyway :-) > Thanks for your assistance and sorry that the bug has been hanging around > for so long. Your welcome. Thank you for your assistance and work! I hope my input helps you in some way.
(In reply to comment #12) > clicking on its icon in the system tray switches to the acitivty where that > application has been started. Unless the tray "abuses" the FromTool mechanism (actually it may do so, because it reacts on user interaction) this would no longer happen with the proposal (the window is instead assigned to the current activity *as well*) > icon is still there). We click on the systray icon. We expect to see KMail's > window but instead nothing happens as the window got minimized to systray in activity 1 That could be an issue in either the SNI (tray icon), SNI protocol, or kmail - could also be that the window is not opened at first because it's not on the current activity (no kmail, no akonadi, no intention to install it ever again) > could be resolved by assigning windows that "come from" the systray That's technically impossible to know. There's a hint whether the window activation was caused by a tool (a taskbar or pager or sth. abusing the feature) or not. That's it. The client (kmail) would have to mark itself on all activities in this case. We neither know that there's a systray, what's in it, whether it was clicked or what happened in return. The WM sees a new Window and the request to activate it (however: windows are *usually* not minimized to the systray but completely closed and recreated. In that case activation happens implicitly (you can try by raising focus stealing prevention to high or extreme - if the request comes from a tool hint, the heuristics are bypassed and the window activated regardless) > To summarize, I'd prefer if activities would get switched automatically as > little as possible. See above. I'd consider it as an explicit request to change the activity if the window on another activity is activated explicitly through the taskbar. Otherwise the window needs to be "copied" to the current activity or simply not be activated at all. I however don't really use activities ...
(In reply to comment #13) > > icon is still there). We click on the systray icon. We expect to see KMail's > > window but instead nothing happens as the window got minimized to systray in activity 1 > > That could be an issue in either the SNI (tray icon), SNI protocol, or kmail > - could also be that the window is not opened at first because it's not on > the current activity (no kmail, no akonadi, no intention to install it ever > again) There is a similar behavior with VLC, for instance. > > could be resolved by assigning windows that "come from" the systray > That's technically impossible to know. would've been too easy I guess :-) > > To summarize, I'd prefer if activities would get switched automatically as > > little as possible. > See above. I'd consider it as an explicit request to change the activity if > the window on another activity is activated explicitly through the taskbar. > Otherwise the window needs to be "copied" to the current activity or simply > not be activated at all. Seems reasonable to me.
http://git.reviewboard.kde.org/r/107761/
(In reply to comment #14) > There is a similar behavior with VLC, for instance. As in kgpg - but it does not work. SNI does a forceful activation. Please try to track the RR since there're more things "suboptimal" in this regard. Also feel free to comment there.