It should be possible to assign the current activity to the window, instead of a fixed one. Reproducible: Always
Do you effectively mean "ALL" activities or do you spot an issue with the preselection?
Related: https://bugs.kde.org/show_bug.cgi?id=302693
> Do you effectively mean "ALL" activities or do you spot an issue with the > preselection? I'm not sure what you mean. Please elaborate. The "current activity" should refer to the current activity when the rule is executed, not when it is created.
If a window is on any activity that is the "current" one that effectively means it is on all activities. -> set the window to be on all activities. If that does not do what you want, you'll have to explain what you want (in behavioral result, do not try to explain how it should work)
Let's say I want my urxvts to appear only on the activity that was active when I started them. I'd create a rule to match `urxvt` in some way and set `activity` to `current`.
Random guess: you use the rxvt w/o a titlebar and are annoyed because it shows upon all activities for that reason (because what you demand is otherwise the default behavior anyway) ie. this is bug #274931 - yesno?
No, I remember seeing another issue where they mentioned that kwin should have an option to by default attach windows to the current activity only.
Who is "they"?
Somewhere in this tracker I think. Can't find it anymore though :-/
Ok, i'm a bit confused. Is this more a thoeritc request then? Don't get me wrong, but status quo is that you seem to want a rule to cause the default behavior, what would only make sense in two cases: a) undecorated (and some docks) windows appear on all activities. -> this needs to be resolved, but correctly - ie. don't map the decoration state or window type to the activity behavior, but have resp. clients hint this demand (my personally preferred solution would be to ship with some stock rules to cover the plasma extenders etc.) b) clients determine a particular set of activities to be on ("ALL" in doubt) while you'd prefer the standard behavior. Given there's no API to set the activity (in kdelibs) property of a window, i'm not aware of any client doing so at all. => Since rules exist to "work around client bugs" or force specific setups, it will be necessary to specify the problem before we can seek for a solution and figure whether that needs a ruleset. To have a decorated uxrvt assigned to the current activity, you don't need a rule - that's supposed anyway; otherwise there's a bug to be fixed.
Oh oke. Then count it as theoretic.