Hi, I have a problem with windows which get to all activities instead of only the current one. Reproducible: Always Steps to Reproduce: 1. Create a window rule to disable window borders, like that one Description=No Borders noborder=true noborderrule=2 types=65 wmclass= wmclasscomplete=false wmclassmatch=0 2. Open a new window Actual Results: The window is now on every activity Expected Results: It should be only on the current activity
@Martin, Chani, Ivan should we not disable the auto-all-activity thing since there's no a rule and also clients can actually hint that themselves? *** This bug has been marked as a duplicate of bug 285055 ***
> @Martin, Chani, Ivan > should we not disable the auto-all-activity thing since there's no a rule > and also clients can actually hint that themselves? +1 from my side
How is it related to the other bug (which is fixed because there are activity rules, which do not help me)?
Auto-all-activity for special windows should stay - panels, panel control window (and thus activity switcher), krunner, lancelot etc. * For other windows, I don't see it active - my windows get the current activity by default. -- * the rationale behind this is that borderless windows usually belong to the workspace (more than not).
@ivan is lancelot dock type? notice that eg. by default chromium has no border either. if the idea is to match "workspace" windows we may want introduce a special property, sharpen heuristics by window relations (eg. make the window transient for the desktop) or simply have it initially hint the "ALL" activities state @jonathan it is the *exact* same condition and outcome - whether the pure ability to control the behavior by rules "fixes" it or not
Thanks for the hints, however you are going to procede, “if (!isMapped /*&& !noborder*/ && isNormalWindow() && !activitiesDefined) {” in manage.cpp works for me. Isn't the isNormalWindow()-condition enough to exclude all the panels etc.?
> simply have it initially hint the "ALL" activities state This would be cool, but before removing the heuristic, the apps need to be patched. So, if this is to be done for 4.9, it should be well-communicated - kde-devel, plasma-devel and planetkde with instructions how to set the XAtom in question. This is something that could eventually end up in libkactivities when KF5 gets out, XAtoms alternative in Wayland is known etc. > is lancelot dock type? No, neither is krunner. Probably the applet browser / activity switcher as well. Don't know about them.
Came across this bug report because i just became affected by it. Its still not fixed in KDE 4.14. Put a window rule of "no borders" and it will start in every activity. There is no way to only make it start on current activity. Also, dont understand how this bugreport is a duplicate, since the other is a way to make it all activities by default, and this one is about being borderless kwin rule not mess with activity placement.