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
I can reproduce it with KDE-4.7.1
I can confirm this unexpected behaviour on KDE 4.7.3. It shows on all activities (including new ones)
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)
is that still an issue in latest versions of KWin?
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 ***
*** Bug 304237 has been marked as a duplicate of this bug. ***
Rules are there, but behavior is unchanged - reopening for some activity sprint
*** Bug 307088 has been marked as a duplicate of this bug. ***
I can reproduce with Google Chrome (it doesn't have a border by default) under KDE4.9.3.
*** Bug 309426 has been marked as a duplicate of this bug. ***
*** Bug 312485 has been marked as a duplicate of this bug. ***
*** Bug 315579 has been marked as a duplicate of this bug. ***
*** Bug 316354 has been marked as a duplicate of this bug. ***
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)
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.
Arrrrrrrr.....This issue is still reproducible in KDE4.11.3 of openSUSE13.1.......orz
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
(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)
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.
This bug~ still exists in KDE 5 Plasma... orz
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.
(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)
Still present in my plasma 5.5.3 setup archlinux hello :)
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.
(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++
(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!
very annoying daily pain, please go for fix
I can confirm on kubuntu 16.04, plasma 5.5.5, qt 5.5.1 very annoying daily pain, please go for fix
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.
(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.
(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 :)
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.
(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
@Ivan: can you please have a look whether the requirement for the noborder restriction is still needed.
I am now kde4 is simply remove the !noborder in if XD
*** Bug 366115 has been marked as a duplicate of this bug. ***
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.
hiding *
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).
That's no longer entirely true, I added moveToActivity to the context menu of the task manager.
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 :)
current warning *
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.
*** Bug 378132 has been marked as a duplicate of this bug. ***
So, any updates on why the !noborder restriction was necessary and if this can be removed at this point?
(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.
This bug affects me too! please tell a solution to me hello : )
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.
Can you not give these plasmashell windows an all-activities flag? (I am still quite unclear what windows, specifically, these are?)
"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?
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!
@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.
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.
@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.
@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?
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.
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.
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?
(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.
@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?
(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.
@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?
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.
(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.
@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.
But if you agree with this then first we have to establish that list, and gather input from others on KWins e-mail-list
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.
Sorry your idea won't work. There is only one place where a Client is created. Client is a KWin internal class.
@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).
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?
I have started using activities and stumbled upon this issue too. Any progress or (at least) workarounds?
(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.
(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.
> 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.
@DimanNe I completely agree with you.
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
> 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
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.
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?
(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.
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
No, we cannot detect that a window belongs to plasma. If all of that were that simple we would have done it.
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.
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.
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?
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!
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.
*** Bug 417793 has been marked as a duplicate of this bug. ***
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.
*** Bug 417618 has been marked as a duplicate of this bug. ***
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)
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
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
hi, are there any plans to backport the fix also to 5.18 version (as used in Kubuntu 20.04 LTS?) thanks
No. We don't do behavioural changes in patch fixes.