Bug 274931 - Windows with no border (decoration) are visible on all activities
Summary: Windows with no border (decoration) are visible on all activities
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: activities (show other bugs)
Version: 5.5.3
Platform: Fedora RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 304237 307088 309426 312485 315579 316354 366115 378132 417618 417793 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-06-04 19:39 UTC by Bruno Kindt
Modified: 2020-06-03 18:04 UTC (History)
40 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.19
Sentry Crash Report:
thomas.luebking: Decision-Required+


Attachments
attachment-4246-0.html (941 bytes, text/html)
2017-09-05 20:56 UTC, Cristóvão Sousa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Kindt 2011-06-04 19:39:17 UTC
Version:           unspecified (using KDE 4.6.3) 
OS:                Linux

When a windows rule (system settings > window behavior > window rules) is present for Konsole with "Preferences/No border" set to "Apply Initially" Konsole will be visible on all activities.


Reproducible: Always

Steps to Reproduce:
- Add rule for konsole in "Window Rules", set "Preferences/No border" to "Apply Initially"
- open new konsole (should have no border visible)
- switch activity
- konsole is visible in every activity

Actual Results:  
konsole is visible in every activity

Expected Results:  
only show Konsole on the activity where it is started

same result for Kate
Comment 1 Jekyll Wu 2011-09-20 00:03:01 UTC
I can reproduce it with KDE-4.7.1
Comment 2 Pieter Vande Wyngaerde 2011-12-02 22:39:45 UTC
I can confirm this unexpected behaviour on KDE 4.7.3.
It shows on all activities (including new ones)
Comment 3 Thomas Lübking 2011-12-03 01:20:45 UTC
From kwin/manage.cpp:

//TODO: if we are keeping it (at least as an option), replace noborder checking
//with a public API for setting windows to be on all activities.
//something like KWindowSystem::setOnAllActivities or
//KActivityConsumer::setOnAllActivities

Since kdelibs is frozen /this/ will have to wait until the frameworks transition is done. (ie. not in the KDE 4 cycle)

@Chani
What's the rationale behind treating "noborder" windows special in this regard?
Did you want to exclude particular windows (of special type, eg. splash screens, plasma extenders or stuff like that) or would *cough* some activity rule *cough* actually be suitable?

(tagging wish since the behavior is at first sight intended)
Comment 4 Martin Flöser 2012-03-13 21:46:04 UTC
is that still an issue in latest versions of KWin?
Comment 5 Thomas Lübking 2012-03-13 22:02:26 UTC
yes, is according to chani more or less a workaround for absent activity window rules, so this is basically a dupe of bug #285055

*** This bug has been marked as a duplicate of bug 285055 ***
Comment 6 Thomas Lübking 2012-09-07 22:00:01 UTC
*** Bug 304237 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Lübking 2012-09-07 22:01:10 UTC
Rules are there, but behavior is unchanged - reopening for some activity sprint
Comment 8 Thomas Lübking 2012-09-20 10:46:15 UTC
*** Bug 307088 has been marked as a duplicate of this bug. ***
Comment 9 ono 2012-12-08 09:58:11 UTC
I can reproduce with Google Chrome (it doesn't have a border by default) under KDE4.9.3.
Comment 10 Thomas Lübking 2012-12-14 17:10:55 UTC
*** Bug 309426 has been marked as a duplicate of this bug. ***
Comment 11 Martin Flöser 2013-01-02 11:51:51 UTC
*** Bug 312485 has been marked as a duplicate of this bug. ***
Comment 12 Thomas Lübking 2013-02-21 21:06:28 UTC
*** Bug 315579 has been marked as a duplicate of this bug. ***
Comment 13 Thomas Lübking 2013-03-18 11:16:50 UTC
*** Bug 316354 has been marked as a duplicate of this bug. ***
Comment 14 ono 2013-03-30 12:31:27 UTC
This issue is still reproducible in KDE4.10.00 "release1" of openSUSE12.3.

(Few people like to disable Firefox and Konsole's titlebar and frame?This issue exist since I began to use Activity when KDE 4.7)
Comment 15 Thomas Lübking 2013-04-10 18:55:19 UTC
I vote for closing this the hard way, ie. just fix it, send a mail to kde-devel to please correctly claim whether you want to be on all activities (with you *normal* window! splashs don't have to be and popups/tooltips are not afffected anyway)

In *very* doubt ship a default rule w/ 4.11 for plasma popups.
Comment 16 ono 2013-12-12 17:15:46 UTC
Arrrrrrrr.....This issue is still reproducible in KDE4.11.3 of openSUSE13.1.......orz
Comment 17 Cristóvão Sousa 2013-12-13 11:49:58 UTC
I've just found a workaround for windows with no system title bar by default.

I use Chromium without system title bar and it was getting spawned to all activities, not only the current one.

I was able to fix this behavior by:
creating a new "Window Rule" for Chromium and in the
    "Appearance & Fixes"
tab checking
    "No title bar and frame"
and setting it to
    "Apply Initially": "No" .

Now, when a new Chromium is started, it appears only on the current activity and desktop, while still not using system title bar.

I'm using KDE 4.11.3 on Arch Linux.

Cheers,
Cristóvão
Comment 18 ono 2013-12-18 13:05:34 UTC
(In reply to comment #17)
> I've just found a workaround for windows with no system title bar by default.
> 
> I use Chromium without system title bar and it was getting spawned to all
> activities, not only the current one.
> 
> I was able to fix this behavior by:
> creating a new "Window Rule" for Chromium and in the
>     "Appearance & Fixes"
> tab checking
>     "No title bar and frame"
> and setting it to
>     "Apply Initially": "No" .
> 
> Now, when a new Chromium is started, it appears only on the current activity
> and desktop, while still not using system title bar.
> 
> I'm using KDE 4.11.3 on Arch Linux.
> 
> Cheers,
> Cristóvão

It's not works on my KDE4.11.3 (openSUSE 13.1)
Comment 19 TOM Harrison 2014-03-14 15:29:14 UTC
still exist in 4.12.3. 
not just chrome, near all window with no title bar include full screen has same problem.
i think it is unpractical to make every rule for it.
Comment 20 ono 2015-09-04 14:37:20 UTC
This bug~ still exists in KDE 5 Plasma... orz
Comment 21 Jim Duchek 2015-09-09 00:34:27 UTC
Problem appears to be line 204 of kwin/manage.cpp

        if (!isMapped && !noborder && isNormalWindow() && !activitiesDefined) {
            //a new, regular window, when we're not recovering from a crash,
            //and it hasn't got an activity. let's try giving it the current one.
            //TODO: decide whether to keep this before the 4.6 release
            //TODO: if we are keeping it (at least as an option), replace noborder checking
            //with a public API for setting windows to be on all activities.
            //something like KWindowSystem::setOnAllActivities or
            //KActivityConsumer::setOnAllActivities
            setOnActivity(Activities::self()->current(), true);
        }

i.e., in most cases (as long as there's a border!), the activity is set to the current one.  Later on the activity 'rule' is checked (if the window has a rule to go to 'all activities' or a specific activity, it will be obeyed).  

The !noborder simply doesn't need to be there -- I'm not sure why it was even there in the first place (what no-border windows were they worried about?), but later on in the code (line 226) there is indeed now rule-matching if a 'set activity' rule is set, so that check can be safely removed.  

If there is some reason SOME no-border windows should go across all activities, there should be a different check for whatever that case is, not ALL no-border windows.
Comment 22 hugo981 2015-10-25 12:41:06 UTC
(In reply to kuanyui from comment #18)
> (In reply to comment #17)
> > I've just found a workaround for windows with no system title bar by default.
> > 
> > I use Chromium without system title bar and it was getting spawned to all
> > activities, not only the current one.
> > 
> > I was able to fix this behavior by:
> > creating a new "Window Rule" for Chromium and in the
> >     "Appearance & Fixes"
> > tab checking
> >     "No title bar and frame"
> > and setting it to
> >     "Apply Initially": "No" .
> > 
> > Now, when a new Chromium is started, it appears only on the current activity
> > and desktop, while still not using system title bar.
> > 
> > I'm using KDE 4.11.3 on Arch Linux.
> > 
> > Cheers,
> > Cristóvão
> 
> It's not works on my KDE4.11.3 (openSUSE 13.1)

I can confirm that it doesn’t work with KDE5 (archlinux)
Comment 23 smldis 2016-01-08 16:12:24 UTC
Still present in my plasma 5.5.3 setup 
archlinux
hello :)
Comment 24 Jim Duchek 2016-02-23 10:47:38 UTC
Is anyone from KDE ever going to fix this?  It's literally a one-line fix (see my comment from September).  I suppose I'm going to have to go through the process of submitting a patch officially, I hate to go through all that effort for a one line fix.  This bug is a daily frustration though.
Comment 25 ono 2016-02-26 14:39:49 UTC
(In reply to Jim Duchek from comment #24)
> Is anyone from KDE ever going to fix this?  It's literally a one-line fix
> (see my comment from September).  I suppose I'm going to have to go through
> the process of submitting a patch officially, I hate to go through all that
> effort for a one line fix.  This bug is a daily frustration though.

Jim Duchek++
Comment 26 Michael Mair-Keimberger 2016-02-28 20:32:45 UTC
(In reply to Jim Duchek from comment #24)
> Is anyone from KDE ever going to fix this?  It's literally a one-line fix
> (see my comment from September).  I suppose I'm going to have to go through
> the process of submitting a patch officially, I hate to go through all that
> effort for a one line fix.  This bug is a daily frustration though.

+1
Would be really nice having that fixed!
Comment 27 jimi 2016-04-28 15:07:21 UTC
very annoying daily pain, please go for fix
Comment 28 jimi 2016-04-28 15:09:27 UTC
I can confirm on kubuntu 16.04, plasma 5.5.5, qt 5.5.1
very annoying daily pain, please go for fix
Comment 29 TOM Harrison 2016-05-13 02:43:58 UTC
could I create a review patch for kde 4 ? I am still using kubuntu 14.04.4. which is only could use kde 4. 
I just remove the !noborder in "line 204 of kwin/manage.cpp" and seems work.
currently it did not have some other effect.
Comment 30 Martin Flöser 2016-05-13 05:43:57 UTC
(In reply to TOM Harrison from comment #29)
> could I create a review patch for kde 4 ? I am still using kubuntu 14.04.4.
> which is only could use kde 4. 

kde 4 is EOL on our side, I don't even have a build setup anymore. We won't do any releases for it and not accept any changes for it. Even if we accepted, no distribution would pick it up as they also don't expect changes anymore.
Comment 31 Jim Duchek 2016-05-13 05:51:14 UTC
(In reply to Martin Gräßlin from comment #30)
> kde 4 is EOL on our side, I don't even have a build setup anymore. We won't
> do any releases for it and not accept any changes for it. Even if we
> accepted, no distribution would pick it up as they also don't expect changes
> anymore.

Well... can we get it fixed in KDE 5 then :)
Comment 32 Martin Flöser 2016-05-13 06:13:19 UTC
The reason for the noborder check is explained in:
http://commits.kde.org/kwin/ff82383f8d8acdc684468a3176e1d048a795209b

By simply reverting as asked for in this bug report, we are ignoring the problems outlined in this commit. This needs a smarter solution.
Comment 33 Jim Duchek 2016-05-13 07:02:47 UTC
(In reply to Martin Gräßlin from comment #32)
> The reason for the noborder check is explained in:
> http://commits.kde.org/kwin/ff82383f8d8acdc684468a3176e1d048a795209b
> 
> By simply reverting as asked for in this bug report, we are ignoring the
> problems outlined in this commit. This needs a smarter solution.

The solution has already been implemented, and the noborder check is a leftover.  I don't have the time right now to dig out all the proper commits (but I will tomorrow if you want me to :).... you'll note in the HEAD version of manage.cpp, there is no more 'isOnAllActivities()' check as there was in this commit, because the proper way for windows to ask to be on all activities has been implemented.  There is an additional comment just below the commit you referenced in manage.cpp:

 //TODO: if we are keeping it (at least as an option), replace noborder checking
 //with a public API for setting windows to be on all activities.
 //something like KWindowSystem::setOnAllActivities or
 //KActivityConsumer::setOnAllActivities

And hi there... Client::setOnAllActivities() exists now -- there is no reason for this hack anymore, although it may potentially be masking bugs in other places wherein they are not properly asking for an all-activities window.  But that is their bug to fix, and no reason to keep this one.  This TODO needs to be removed along with the noborder check as well, I guess, lest it confuse future code browsers.

The commit comment makes one still-valid point, in that indeed, users who WANT a no-border window to be on all activities, will need to figure out alt-f3, which is not obvious... But that is better than the current situation, wherein users who want no-border windows to act 'normally' have to figure out alt-f3.  Somebody's going to need to find alt-f3 either way when it comes to no-border windows, and IMHO it should be the people who want the non-standard behavior.

Jim
Comment 34 Martin Flöser 2016-05-13 07:40:35 UTC
@Ivan: can you please have a look whether the requirement for the noborder restriction is still needed.
Comment 35 TOM Harrison 2016-05-13 13:15:26 UTC
I am now kde4 is simply remove the !noborder in if
XD
Comment 36 Martin Flöser 2016-08-01 07:25:48 UTC
*** Bug 366115 has been marked as a duplicate of this bug. ***
Comment 37 Łukasz 2017-02-04 05:12:42 UTC
Fixing this error, and global menu for GTK - only this is needed for happiness. No border, hidden global menu and hidden the main panel - more space than in Unity.
Comment 38 Łukasz 2017-02-04 05:14:18 UTC
hiding *
Comment 39 Ivan Čukić 2017-02-07 11:32:01 UTC
One of the reasons for this (I don't remember all of them) is that in a borderless window, moving to another activity is not possible (unless for geeky users that know of alt+f3).
Comment 40 David Edmundson 2017-02-07 11:34:42 UTC
That's no longer entirely true, 
I added moveToActivity to the context menu of the task manager.
Comment 41 Łukasz 2017-02-07 12:32:45 UTC
Ivan, it should never be a reason because the person using these options is likely to be aware of what they are doing - 
the amount of custom options scares regular user. In my opinion warning of the need to use ALT + F3 it is a very good option :)
Comment 42 Łukasz 2017-02-07 12:34:25 UTC
current warning *
Comment 43 solitone 2017-02-21 05:59:22 UTC
This still happens with Chrome (when "system titlebar and borders" are not used, which is the default) in kwin 5.8.2 (debian stretch).

I've tried Cristóvão's fix:
(In reply to Cristóvão Sousa from comment #17)
> I've just found a workaround for windows with no system title bar by default.
> 
> I use Chromium without system title bar and it was getting spawned to all
> activities, not only the current one.
> 
> I was able to fix this behavior by:
> creating a new "Window Rule" for Chromium and in the
>     "Appearance & Fixes"
> tab checking
>     "No title bar and frame"
> and setting it to
>     "Apply Initially": "No" .
> 
> Now, when a new Chromium is started, it appears only on the current activity
> and desktop, while still not using system title bar.

However when I start Chrome, it appears only on the current activity, but it does use system title bar.
Comment 44 Martin Flöser 2017-03-27 05:10:31 UTC
*** Bug 378132 has been marked as a duplicate of this bug. ***
Comment 45 Amit 2017-03-27 11:30:26 UTC
So, any updates on why the !noborder restriction was necessary and if this can be removed at this point?
Comment 46 TOM Harrison 2017-07-20 03:43:34 UTC
(In reply to Amit from comment #45)
> So, any updates on why the !noborder restriction was necessary and if this
> can be removed at this point?

actually no, I have tested that. remove that will causing plasmashell no border popup will also stock on single activity.
it need more condition there to let it work both chrome and plasmashell popup widget.
Comment 47 manas n 2017-08-10 09:04:51 UTC
This bug affects me too! please tell a solution to me 
hello : )
Comment 48 Martin Flöser 2017-08-10 14:48:28 UTC
Please don't add further "me too". We know it's an issue, we just lack an idea how to solve it. Sorry for any inconvenience it raises.
Comment 49 Jim Duchek 2017-08-10 15:26:42 UTC
Can you not give these plasmashell windows an all-activities flag? (I am still quite unclear what windows, specifically, these are?)
Comment 50 Arash B 2017-09-02 16:40:12 UTC
"programs like chromium - since there's no border, there is no obvious way of moving them between activities. (alt+f3 menu is not commonly known)" (quote from the commit that Martin Flöser uses as rationale to not fix this problem)

Oh my freaking God! Is this the reason why I've endured this plague? So I shouldn't think of this as a bug but is actually supposed to be a kind and benelovent **coughing coughing** feature that I should be grateful for?

You place the borderless window in ALL activities because you're being so considerate and kind towards the novice user since they won't otherwise know how to place the window in all activities by themselves? Did it every freaking occur to you that the same user will by the same reason be clueless as to how restrict the window to only the current activity!?!?!?

If that novice user won't know how to place the borderless window in all activities since the window border isn't there, then how how do you freaking suppose he will be able to restrict the window to only the current activity when you are being so smart as to splash it over all activities?

Do you know anything at all about computer human interface design?? Like anything at all, or are you just working at random!?! If you know some then you should know that one of the holy grails of this topic is FREAKING USER EXPECTED SYSTEM BEHAVIOUR and that you DO NOT mess with this unless you have an extremely good reason, something which you have clearly lacked for the last six years since you were as kind to introduce this nice "feature".

What is the user's expectation of system behaviour when he opens a borderless window/app? It is that the window/app should be placed in the CURRENT ACTIVITY only! Why is this the correct answer? Because this is the DEFAULT BEHAVIOUR when the user opens a window/app that has a border! Since a window/app with a border is placed in the current activity, and since 99.999% of all windows/apps that the user opens have a border (and this applies especially to novice users), this makes the user's expected system behaviour to be that ALL windows/apps are placed in the current activity where they were opened!

How much more clearly does this have to be stated?
Comment 51 Arash B 2017-09-02 16:52:05 UTC
And what do you mean you have to do this since "novice users don't know of alt+f3 when there's no border"?! If you wan't to move a borderless window between activities then you simply and gently right click on its entry in the TASK MANAGER, and from the right-click menu you go to "Move to Activity >" and choose whatever you desire.

So your rationale that "there won't be an easy way for the the novice user to place a borderless window on all activities" is further incorrect. But heck it was incorrect from the start because right now by the same token there's no "easy" way for the novice user to restrict the borderless window to the current activity only! And the latter mentioned state will be desired much more often by a novice user.

Placing windows on all activities by default BREAKS the purpose of using activities!
Comment 52 Martin Flöser 2017-09-02 17:01:58 UTC
@Arash: your comments are not helpful. Please have a look at https://www.kde.org/code-of-conduct/ about how we work with each other.

Such behavior is not acceptable and I don't tolerate this in KWin bugs.
Comment 53 Arash B 2017-09-02 17:13:06 UTC
My comment is perfectly helpful in that it explains system expected behavior in this particular case and points out the flaws in your rationale for not doing anything about this over many years when it has been pointed out time and time again but been met by comments such as "Please don't add further 'me too'.".

The tone of my comment is a result of seeing this thread that spans six years and understanding the lack of computer human interface design knowledge in the design of KDE, something that plagues me in my day to day work. If you want to use that as an excuse to not fix this problem for another few years then please be my guest. You clearly know how to proceed to achieve that.

I seriously came here expecting this to be an unnoticed bug needing reporting. Seeing that it's a "feature" spanning six years and being protected... wow now that was a real eye opener in need of some venting. You can at least have appreciation for me taking time from my Saturday evening to point out this problem that shouldn't have been a problem over half a decade, despite my tone. And if you do not wish to do so then again proceed as you wish.
Comment 54 smldis 2017-09-03 10:12:49 UTC
@ArashB You are entirely wrong about the fixing policy of this of Martin since his last comment is: 
"Please don't add further "me too". We know it's an issue, we just lack an idea how to solve it. Sorry for any inconvenience it raises."

I follow kde development and I know Martin has a lot of higher priority stuff in his todo queue. So, don't be angry and help the community in a proper way.

Is it ok to open a task at https://phabricator.kde.org/project/view/98/ ?
For idea proposals, since we still don't have a proper solution I would ask if is it possible to have an environment variable that control this no border policy since when I tried to use activities this was what stopped me to transit to an activity based workflow.
Comment 55 Arash B 2017-09-03 14:24:08 UTC
@martin @smldis

The solution that has been implemented is wrong and should be removed. When the user opens a borderless window then that window should be placed in the current activity where it was opened.

The reasons for this are twofold.

Firstly, this is (by the user) the expected system behavior. This is the expected bhavior because all other windows that have a border are placed in the current activity when opened. In nearly every workflow almost all windows have borders, and so when it happens nearly every time that the window is placed in the current activity then this becomes an expected behavior.

Secondly, even if the user would like to change the window's activity settings then there's a very easy way even if there's no border; the user simply locates the window's entry in the task manager at the bottom of the screen and right clicks it. Then the user selects the entry "Move to activity >" from the menu. From there the user can select "Show on all activities", and thus the user has easily accomplished what you're concerned he won't be able to do without a window border.

Is there anything in this argument that you regard incorrect?
Comment 56 solitone 2017-09-03 18:35:12 UTC
Arash, I would also expect the behaviour you are describing, but I suspect there is some technical constraint which does not allow to implement it easily.
Comment 57 Martin Flöser 2017-09-03 19:23:21 UTC
I'm now giving some background information: the behavior in question was implemented in 2010, that is 7 years ago! Back then the world of windows looked differently. Chromium was basically the only application which existed with client side decorations and back then it was brand new (initial release 2008 according to Wikipedia). Spotify did not yet exist, neither did GNOME use client side decorations (though Ubuntu thought about it: https://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/ ). When introducing activities the implementation assumed that windows without decorations are in a specific way special and should be on all activities. Back then this was a valid approach and absolutely correct!

Given that it does not make any sense to question the code as it is today. Yes, the way applications interact changed and the assumptions don't hold any more as general as they did back in 2010.

Changing the code would be a good idea and that might happen eventually. Unfortunately it will not have any priority. Activities is still not a fully understood topic in the case of window management and the core development team is not investing time into it as long as we don't know where the road takes us.

For example our Activity related code does not support Wayland yet. It's one of the last areas in KWin which is not yet adjusted for Wayland (other areas are window rules and focus stealing prevention).

As long as this is not adjusted for Wayland, I don't expect anything to happen on X11. We need a general solution for the problem - we didn't find one the last seven years, I don't expect that we magically find it tomorrow. Maybe Wayland will help us to find a solution, after all we had several other areas where we could fix problems by looking at it from a different Wayland angle.

But personally I don't expect that Activities will see a Wayland port anytime soon.

I'm sorry for the inconvenience this issue creates for our users. But I'm also asking to not discuss it further in this bug report: it won't help. Your comments won't change the priority of this bug, I'm sorry. The priority is low as we don't know where the activities road takes us in the window manager world.
Comment 58 Arash B 2017-09-04 18:52:46 UTC
Ok but I have cloned the kwin git repo (https://github.com/KDE/kwin) to have a look for myself. I was wondering if you could show me where the function body of 

   bool WindowRules::checkNoBorder(bool noborder, bool init = false) const

is. I've found its definition in rules.h but the function body is nowhere to be found in the repo.

Is it correct that the function WindowRules::checkNoBorder is called from line 184 in

   bool Client::manage(xcb_window_t w, bool isMapped)

in clients.cpp?
Comment 59 Martin Flöser 2017-09-04 19:24:47 UTC
(In reply to Arash B from comment #58)
> Ok but I have cloned the kwin git repo (https://github.com/KDE/kwin) to have
> a look for myself. I was wondering if you could show me where the function
> body of 
> 
>    bool WindowRules::checkNoBorder(bool noborder, bool init = false) const
> 
> is. I've found its definition in rules.h but the function body is nowhere to
> be found in the repo.

rules.cpp:856

> 
> Is it correct that the function WindowRules::checkNoBorder is called from
> line 184 in
> 
>    bool Client::manage(xcb_window_t w, bool isMapped)
> 
> in clients.cpp?

Yes, but there are more usages.
Comment 60 smldis 2017-09-04 19:43:05 UTC
@ArashB, did you tried the previously posted solution? (delete the !noborder check here):

Problem appears to be line 204 of kwin/manage.cpp

        if (!isMapped && !noborder && isNormalWindow() && !activitiesDefined) {
            //a new, regular window, when we're not recovering from a crash,
            //and it hasn't got an activity. let's try giving it the current one.
            //TODO: decide whether to keep this before the 4.6 release
            //TODO: if we are keeping it (at least as an option), replace noborder checking
            //with a public API for setting windows to be on all activities.
            //something like KWindowSystem::setOnAllActivities or
            //KActivityConsumer::setOnAllActivities
            setOnActivity(Activities::self()->current(), true);
        }

If that works an easy fix would be exposing an environment variable to chose the default behaviour, right?
Comment 61 TOM Harrison 2017-09-04 23:49:19 UTC
(In reply to smldis from comment #60)
> @ArashB, did you tried the previously posted solution? (delete the !noborder
> check here):
> 
> Problem appears to be line 204 of kwin/manage.cpp
> 
>         if (!isMapped && !noborder && isNormalWindow() &&
> !activitiesDefined) {
>             //a new, regular window, when we're not recovering from a crash,
>             //and it hasn't got an activity. let's try giving it the current
> one.
>             //TODO: decide whether to keep this before the 4.6 release
>             //TODO: if we are keeping it (at least as an option), replace
> noborder checking
>             //with a public API for setting windows to be on all activities.
>             //something like KWindowSystem::setOnAllActivities or
>             //KActivityConsumer::setOnAllActivities
>             setOnActivity(Activities::self()->current(), true);
>         }
> 
> If that works an easy fix would be exposing an environment variable to chose
> the default behaviour, right?

I have deleted that and tried, it actually solve but create another issue. That will causing the other no border that belong to plasma, ex. network manager widget, will also show only on one activities which is in-convenience.
Comment 62 Arash B 2017-09-05 08:01:56 UTC
@martin @tom

So this is my assessment of the situation: the border property is incorrectly used to determine if a window should be placed on all activities, when in fact other indicators should be used instead to make this assessment. This is because using the border property will place certain windows (such as chrome) on all activities when they shouldn't be.

I'm therefore trying to make a complete and distinct list of types of windows that should be placed on all activities. I want to use this list to try to create logic (in the code) that correctly determines if a window element should be on all activities. I will create such logic on my own and then present them in this thread for review and discussion, but someone else would have to finally incorporate them in the software.

Here is a highly partial and vague start of the list of types of window elements that should be placed in all activities when created:

* plasma extenders
* applet browser
* activity manager

Could you help me with two things? Firstly, could we complete this list by adding all types of window elements that should be placed on all activities? Secondly, could we make the list more granular by dividing each list item into subcategories? For instance I'm thinking plasma extenders is a broad category encompassing many different *types* of things. I don't need to know every conceivable plasma extender that there's, but only relevant *types*.

If certain types of window elements require different method of procedures to determine their type, then it would be very appreciated if they are mentioned distinctively as a separate subcategory. For instance maybe a different set of function calls has to be made to determine their type, while other functions are used for other window element types.

I'm assuming each of these window elements of this list are represented by an instance of the class KWin::Client, and that for all of them it is determined in manage.cpp on line 234 by the following statement

...
if (Activities::self() && !isMapped && !noborder && isNormalWindow() && !activitiesDefined) {
...

Are these two assumptions correct? Or is it (possibly further) assessed somewhere else whether if or not the window element should be placed on all activities?
Comment 63 Arash B 2017-09-05 08:12:31 UTC
On a different point, I would advice that full function definition is written as a comment above where macros are used to write function header and body. It would for instance look like this in rules.cpp line 856:

// Function body declaration of bool WindowRules::checkNoBorder( bool arg, bool init ) const
CHECK_RULE(NoBorder, bool)

This way the function name will actually be searchable with a tool like grep. I spent the better part of an hour trying to locate this, and was at last thinking that the function body declaration is somehow linked from a library or another repo of code.

It will take some time to add such comments but it will be worth it and save time in the end.
Comment 64 Martin Flöser 2017-09-05 16:48:57 UTC
(In reply to Arash B from comment #62)
> Here is a highly partial and vague start of the list of types of window
> elements that should be placed in all activities when created:
> 
> * plasma extenders
> * applet browser
> * activity manager

I'm sorry, but such a list won't help you to fix this issue. These are normal windows, the only special thing is that they are not window decorated. There is no hint like "that's an applet browser" on X11, it just looks like any other window.

If it were that simple it would not have taken us seven years.

> 
> Are these two assumptions correct? Or is it (possibly further) assessed
> somewhere else whether if or not the window element should be placed on all
> activities?

I wouldn't be surprised if there are more places. I'm sorry I cannot really tell you where. The activities code is an area I have not contributed to and also not reviewed when it got merged.
Comment 65 Arash B 2017-09-05 20:29:36 UTC
@Martin

Ok then but we should create such a complete list for the purpose introducing logic that allows us to discern different window elements from each other (for instance for the purpose of determining whether if or not a window element should be on all activities).

In the end they are all represented by an instance of the class Client, is this correct? I propose that a new instance variable is introduced in the class Client called kdeWindowType. Its value is decided by an enum with as many possible values as there are discernible types of kde window elements (hence why we need that complete list). But the enum also has an extra value called UNKNOWN.

By default, every time a Client instance is created kdeWindowType is simply put to UNKNOWN. No further changes are introduced in your repo at the time. This way this change doesn't break KDE or introduce any new bugs at all, because kdeWindowType is only written to, never read.

Then I can hunt down all other KDE git repos where instances of your Client class are created, and ask the devs to correctly set the value of kdeWindowType by passing on the correct argument value (determined by the enum) when making the call to create a Client class.

And then in the future, determining the type of a window element will just be a getKdeWindowType() call away... This change will take lots of time but solve many of your problems in the future. Things will have to get messy before they get any better...

Do you agree with this? All you have to do is to introduce the class instance variable kdeWindowType and the enum.
Comment 66 Arash B 2017-09-05 20:32:08 UTC
But if you agree with this then first we have to establish that list, and gather input from others on KWins e-mail-list
Comment 67 Cristóvão Sousa 2017-09-05 20:56:26 UTC
Created attachment 107708 [details]
attachment-4246-0.html

Hi all,
Can't the same mechanism that decides whether windows are placed in current
or all desktops be used for activities?

On Tue, Sep 5, 2017 at 9:32 PM Arash B <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=274931
>
> --- Comment #66 from Arash B <arashu@gmail.com> ---
> But if you agree with this then first we have to establish that list, and
> gather input from others on KWins e-mail-list
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 68 Martin Flöser 2017-09-06 04:29:02 UTC
Sorry your idea won't work. There is only one place where a Client is created. Client is a KWin internal class.
Comment 69 Arash B 2017-09-06 04:56:26 UTC
@Martin

Well then we go a step further out; some part of some api/interface (class constructor, public function, etc.) is used by others to signal to KWin that a window element should be created. Calling this api/interface part further leads to the creation a Client class instance, correct?

Then add kwinWindowType to this api/interface part but give it a default value of UNKNOWN if the corresponding arg isn't passed on when the api/interface part is called. Then further pass on the value of kwinWindowType to the Client constructor (or Client::manage() which seems to serve instead of a constructor).
Comment 70 Arash B 2017-09-06 12:59:54 UTC
Aha! Workspace::createClient is part of Kwins public Api, correct? You can overload it and add enum var clientType. Its default value is NORMAL_APP but there will also be enum values such as PLASMA_WIDGET, PLASMA_EXTENDER, etc..

In time, we can ask other devs to set clientType appropriately when calling createClient. Is this a good approach?
Comment 71 DimanNe 2018-02-03 16:02:18 UTC
I have started using activities and stumbled upon this issue too. Any progress or (at least) workarounds?
Comment 72 Martin Flöser 2018-02-03 16:41:48 UTC
(In reply to Arash B from comment #70)
> Aha! Workspace::createClient is part of Kwins public Api, correct? 

Sorry, I missed your question. You are unfortunately not correct. KWin does not have any kind of public API other applications could use. The communication happens only via X11 or Wayland protocol.
Comment 73 Martin Flöser 2018-02-03 16:46:36 UTC
(In reply to DimanNe from comment #71)
> I have started using activities and stumbled upon this issue too. Any
> progress or (at least) workarounds?

As you can see this is a long standing issue dating back to 2011. If we could apply a workaround, we would have done it years ago. The current situation is that:
 * X11 will not see any more features
 * Wayland lacks Activity support in general

On Wayland that would be easier to address. There we have a dedicated protocol for Plasma windows already, so we could easily mark them as on all activities without having to go through the window decoration Hack.

Unfortunately we don't have activities support yet as there is no clear understanding on where to go with activities from window management perspective and how they relate to virtual desktops.

This has been a problem on X11 as well and is certainly part of why this issue did not get addressed. Resulting in activity support being more or less unmaintained in KWin.
Comment 74 DimanNe 2018-02-03 20:57:01 UTC
> As you can see this is a long standing issue dating back to 2011. If we
> could apply a workaround, we would have done it years ago. The current
> situation is that:
>  * X11 will not see any more features
>  * Wayland lacks Activity support in general

Well, of course, it is wiser to invest resources in improving and supporting shiny new wayland instead of obsolete XOrg, which is in its senectitude.

> Unfortunately we don't have activities support yet as there is no clear
> understanding on where to go with activities from window management
> perspective and how they relate to virtual desktops.

While it is not too late, as a KDE user, I would suggest that the current relation of activities to virtual desktops is convenient. The fact that I have separate set of virtual desktops in each activity totally corresponds to my workflow.

Anyway, thanks for the clarification.
Comment 75 Łukasz 2018-02-05 15:27:23 UTC
@DimanNe I completely agree with you.
Comment 76 Alexander Mentyu 2018-04-04 14:02:58 UTC
Proposal - when KWin detects window without decorations - and there are two or more activities - it could display notification window with explanations regarding to moving the app window with keyboard Alt+F3 shortcut and right click task menu moving options - with 'Do not show this window again' checkbox (possibly checked by default) - the app window is displayed on current activity only
Comment 77 Alexander Mentyu 2018-04-05 16:37:38 UTC
> Proposal - when KWin detects window without decorations - and there are two
> or more activities - it could display notification window with explanations
> regarding to moving the app window with keyboard Alt+F3 shortcut and right
> click task menu moving options - with 'Do not show this window again'
> checkbox (possibly checked by default) - the app window is displayed on
> current activity only

Similarly to fullscreen notification window - after pressing right mouse button on titlebar -> More Actions -> Fullscreen
Comment 78 EECOLOR 2018-07-17 21:46:57 UTC
It is clear the 'offending' if statement can not be changed without a lot of work. There are however two ways around this, the first:

  if ((unchangeable && part) || other)

where `other` could come from the rules. From what I can tell (as a noob in C++ and kwin) there is another more elegant option as well. It seems that the window rules are applied at a later state in the code and there is an option an option available for `Activity` that currently has the following options:

- All activities
- Activity X
- Activity Y

In my naive mind it should be quite easy to add the option 'Current activity'. That way I could just add the rules for the few programs I want to force on the current activity. As it happens, I already have such a rule to disable the border.
Comment 79 Arash B 2018-10-19 21:32:57 UTC
How come you say there's no easy way to fix this when the user can manually restrict a borderless window to the current activity? If this can easily be done manually, then it should be doable programatically. 

Even if an app opens in a borderless window (and thus the window appears in all Activities), then I can through KDE Plasma’s GUI (manually) make it to only appear in the current Activity. I just have to follow these steps:

Press Alt+F3.

Click sub-menu Activities.

Choose the current activity.

My question is if this can immediately be done manually on a borderless window, then why can’t it be done programmatically and automatically by KDE plasma? At least the silly solution to programmatically do the above three steps is available. I.e. KDE plasma is programmed to execute the following steps

If a borderless window is created then
	Execute Alt+F3 (but don’t show the menu on the GUI)
	Enter sub-menu Activities
	Select the current Activity

What is the problem that makes this solution not applicable?
Comment 80 Martin Flöser 2018-10-20 05:13:37 UTC
(In reply to Arash B from comment #79)
> What is the problem that makes this solution not applicable?

It would break every plasma window such as the application launcher, notifications, etc.
Comment 81 Arash B 2018-10-20 17:20:27 UTC
But KDE Plasma can detect if a borderless window is a Plasma window (such as application launcher or notification). Thus, if a borderless window appears and IS a plasma window then KDE Plasma does NOT have to apply this fix. If however a borderless window appears and is NOT a plasma window then KDE Plasma can apply this fix.

If a borderless window is created then
	
	If the borderless window is a Plasma window then
		
		Do nothing
	
	Else
		
		Execute Alt+F3 on the window (but don’t show the menu on the GUI)
		Enter sub-menu Activities
		Select the current Activity
Comment 82 Martin Flöser 2018-10-21 07:06:24 UTC
No, we cannot detect that a window belongs to plasma. If all of that were that simple we would have done it.
Comment 83 Arash B 2018-10-21 16:14:32 UTC
But there's a satisfying alternative solution: Add "Current Activity" to the attribute "Activity" in an applications "Special Application Settings".

I'm specifically talking about the settings you see when you from a window navigate this way: Click its icon to the top left on its title bar (or press Alt+F3) >> More Actions >> Special Application Settings >> the Size & Position tab >> the Activity attribute >> Drop-down list.

Add "Current Activity" to said drop-down list. It's self explanatory what the option should do. This way the user can for instance for the app "google-chrome" fix this undesirable behavior. It's not a perfect fix but still very good and convenient, given the circumstances.

Currently I've tested this for Google Chrome when you choose a specific activity from the drop-down list. The Google Chrome will only appear in that activity, even if the window is borderless when it opens.

The only scenario that is a down-side to this solution (and it's a far-fetched scenario) is that the chosen setting will apply itself to some *other* application also named "google-chrome" (this is the far-fetched part, that some other random app is also called "google-chrome").

But what will happen then is that that other application too will be restricted to the current activity, which is most likely the user's desired system behavior anyway.
Comment 84 Martin Flöser 2018-10-21 16:18:47 UTC
I'm sorry, but also this idea would not work due to the fact how KWin internally works. I'm sorry, that we cannot resolve the problem. As everyone can see it is now seven years old and has many users following it. We did spend lots of time to find a solution zhis includes that there are no easy fixes.

Like so many things: Wayland will fix it as we are completely rethinking virtual desktops and activities.
Comment 85 Arash B 2018-10-21 16:38:56 UTC
How come that KDE Plasma can restrict all windows of an app to a specific activity (by using its Special Application Settings) but it isn't possible to restrict them to the *current* activity?

KDE Plasma can discern what application a newly appeared window belongs to (otherwise the Special Application Settings wouldn't work) and it can do this *even* if the window is borderless.

KDE Plasma can also discern what is the currently selected activity (since it manages to correctly put newly appeared windows with borders in the current activity).

So the two pieces of logic are already in place and working, now they need to be used to add a new small feature.

Of course *some* source code must be added to add the option "Current Activity" to said drop-down list and make it work. But besides from that how could it possibly be so that KDE Plasma is too fundamentally flawed that adding this feature would require redoing KDE Plasma from the ground up?
Comment 86 Arash B 2018-10-21 16:57:08 UTC
Assuming specialSettings represents an instance of a Special Application Settings, then logic dictates that somewhere in KDE Plasma's source code the following if-statement *already* exists:

if specialSettings.position.activity is set then

	if specialSettings.position.activity is set to "All Activities" then

		make window to appear on all activities

	else if specialSettings.position.activity is set to specific activity then

		make window to appear on specified activity only

Now a new else if branch needs to be added to the inner if-statement (for when activity is set to "Current Activity"). Or could you please explain how KDE Plasma works so fundamentally different from this, because it makes no sense at all!
Comment 87 Martin Flöser 2018-10-21 19:03:41 UTC
I'm sorry but your understanding of the KWin rules implementation is unfortunately not how it works. Please trust a Dev knowing the code base that there's no easy fix.
Comment 88 David Edmundson 2020-02-17 15:31:28 UTC
*** Bug 417793 has been marked as a duplicate of this bug. ***
Comment 89 David Edmundson 2020-02-17 15:33:32 UTC
Since the time of this report the task manager has been set to show and allow changing activities through the context menu.

The activity pager also has gained activity drag and drop support.

I think we can now safely change this to check the window type + if skip_taskmanager  instead of decorations.
Comment 90 Vlad Zahorodnii 2020-02-17 15:35:36 UTC
*** Bug 417618 has been marked as a duplicate of this bug. ***
Comment 91 Oded Arbel 2020-02-25 14:26:03 UTC
Just FYI, and regarding 5.18 work on GTK_FRAME_EXTENTS and good GNOME CSD support: 

Without the gtk3-nocsd hack, all GNOME applications show on all activities by default, this isn't just about Google Chrome

(GNOME was mentioned here in passing, but I just tested and wanted to align everyone on the fact that activities break in the presence of the other 50% of the Linux desktop market)
Comment 92 David Edmundson 2020-02-28 11:42:11 UTC
Git commit 41b02f235626b35344d3cb7268c6c16dde01f37a by David Edmundson.
Committed on 28/02/2020 at 11:41.
Pushed by davidedmundson into branch 'master'.

[x11client] Make activity handling more consistent across windows

Summary:
Typically by default newly added toplevel windows are added only to the
current activity.

Initially windows with no borders were added to all activities. This
causes problems particularly now with the newer frame extents support
leaving window behaviour quite inconsistent.

Since the time of the original code the taskbar gained control for
controlling activities allowing at least one method of changing them.
This means we can use this as the new filter.

Test Plan:
Opened gtk3-demo
Switched activities, it wasn't on the new one
Went back, altered it through the taskmanager, it worked

Reviewers: #kwin, zzag

Reviewed By: #kwin, zzag

Subscribers: zzag, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D27690

M  +1    -1    x11client.cpp

https://commits.kde.org/kwin/41b02f235626b35344d3cb7268c6c16dde01f37a
Comment 93 David Edmundson 2020-03-03 14:26:16 UTC
Git commit 148ed53e11d79c8aeffcf2af3e499a43645cfa16 by David Edmundson.
Committed on 27/02/2020 at 01:00.
Pushed by davidedmundson into branch 'davidedmundson/simplify_outputs'.

[x11client] Make activity handling more consistent across windows

Summary:
Typically by default newly added toplevel windows are added only to the
current activity.

Initially windows with no borders were added to all activities. This
causes problems particularly now with the newer frame extents support
leaving window behaviour quite inconsistent.

Since the time of the original code the taskbar gained control for
controlling activities allowing at least one method of changing them.
This means we can use this as the new filter.

Test Plan:
Opened gtk3-demo
Switched activities, it wasn't on the new one
Went back, altered it through the taskmanager, it worked

Reviewers: #kwin

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D27690

M  +1    -1    x11client.cpp

https://commits.kde.org/kwin/148ed53e11d79c8aeffcf2af3e499a43645cfa16
Comment 94 catchman 2020-05-06 20:31:47 UTC
hi, are there any plans to backport the fix also to 5.18 version (as used in Kubuntu 20.04 LTS?)

thanks
Comment 95 David Edmundson 2020-05-06 20:36:15 UTC
No. 

We don't do behavioural changes in patch fixes.