Applying Special Application/Window settings is inconsistent, sometimes working and sometimes not. The first example might be unusual: I have two laptops running Plasma 5. They both have two different versions of Firefox running (running from separate directories). Identical installations on both laptops. On one laptop I can successfully set the separate instances of Firefox to appear in separate activities (the preferences will be stored). On the other, I can't (the preferences aren't stored). I have to reset both instances of Firefox manually each time I invoke the browsers. And then a more common use-case: gthumb (which I prefer to Gwenview). I cannot permanently (through Special Application settings) assign gthumb to one Activity. Plasma resets my preferences to "All Activities" as soon as I close the dialog window. Reproducible: Always Steps to Reproduce: 1. alt+f3 Set gthumb to a specific activity. 2. Close window. 3. Reopen Actual Results: ghtumb re-assigned to *all* activities. Expected Results: assignment to preferred activity. Kernel: 4.4.0-16-generic x86_64 (64 bit) Desktop: KDE Plasma 5.5.4 Distro: Ubuntu 16.04 xenial
Is the "inconsistency" strictly related to activity assignment? Ie. can you successfully assign a virtual desktop, a fixed geometry, or keep above position (etc.)?
Yes, I can successfully assign a fixed geometry and keep it above others. It will also retain a virtual desktop assignment but... just noticed another bug. I have 2 activities and two virtual desktops in each. KWIN only gives me the option to assign gthumb to 1:1 or 2:2. In other words, no options for 1:2 or 2:1.
Since only one system is affected, I sense troubles reg. the activity manager - how many activities are listed in the alt+f3 menu ("set on activity ...")
Hi Thomas, in reference to gthumb, both activities are correctly listed under altf3.
can you please attach ~/.config/kwinrulesrc after applying the activity rule (but before restarting the client) and post the output of qdbus org.kde.ActivityManager /ActivityManager/Activities ListActivities along?
Created attachment 98217 [details] kwinrulesrc Not 100% sure what you mean by "before restarting client". Assume you mean before restarting gthumb or either instance of FF.
:~$ qdbus org.kde.ActivityManager /ActivityManager/Activities ListActivities 252a0153-22c9-4308-af0d-cd52f865cf83 30e27801-8b2d-498f-ab4a-1ca39cb629df
Well, there's no activity rule for either firefox or gthumb. "tomboy", "kradio4" and something called "wrapper-1.0" are set to be on all activities, thunderbird on 30e27801-8b2d-498f-ab4a-1ca39cb629df, so assigning activiites generally works. run "kcmshell5 kwinrules", use the detect button on gthumb or firefox, try to assign an activity this way and report outcome as well as updated rules.
So, wrapper-1.0 was me trying to improve XFCE4 Panel's behavior in Plasma5. I use XFCE4-Panel because I really like the Weather & Dictionary App. However, getting the Dictionary App to "visibly" pop up is inconsistent. I usually have to clear the Desktop and *then* click the Dictionary App (on the XFCE4 Panel) before it will "visibly" pop up. It will also only pop up in the first/default activity. I tried experimenting by assigning Application rules to the Dictionary App but what resulted is what you saw. I don't know whether this should considered a "bug" so much as general incompatibility. If you think this deserves a separate Bug Report, I'll file one. Meanwhile, I used "kcmshell5 kwinrules", as suggested, and gthumb appears to be behaving. Interestingly, "kcmshell5 kwinrules" doesn't appear to differentiate between the two versions of Firefox. FYI: To invoke Repository Firefox: firefox %u -P default To invoke the manually "installed" version of Firefox; /home/vtpoet/.icefox/firefox/firefox -no-remote -P icefox So, the two FF's are working out of entirely separate directories. One is updated via the repository, one is manually updated. I use two FFs in two separate Activities because I run separate blogs and having separate instances of FF allows me to be logged into both at the same time and logged into separate Gmail accounts at the same time. I'm going to check my other install and see if I can figure out why it's working on that system and not the one I'm writing from. That system still uses 15.10 but is updated with Kubuntu backports.
Okay, writing from my other system: Kernel: 4.2.0-34-generic x86_64 (64 bit) Desktop: KDE 5 Distro: Ubuntu 15.10 wily If I try to edit special window settings for my two instances of FF, nothing sticks. If I edit application settings, the settings stick but are applied to both instances of FF. If I individually apply settings via right clicking the window border: Activities --> X or Y Then the assignments stick, even after closing and rebooting either instance of FF. The only difference (besides version of KDE -- and these issues still applied when I was running 15.10 on both) is that I am activating the successful system via right clicking the window border. Since I've deactivated window borders on my other system (smaller screen real-estate) I access the same options via ALTF3. Don't know if that makes a difference. Will test. The contents of .config/kwinrulesrc are empty on this system. Also, being 15.10, this system uses the older version of GThumbvand so isn't an issue.
> The contents of .config/kwinrulesrc are empty on this system. KDE 4? => ~/.kde/share/config/kwinrulesrc > I usually have to clear the Desktop and *then* click the Dictionary App (on the XFCE4 Panel) before it will "visibly" pop up. Sounds like it's less a popup but more a normal window that is running into the focus stealing protecion? > Meanwhile, I used "kcmshell5 kwinrules", as suggested, and gthumb appears to be behaving. Ok, we can likely pin it down a some sync issue when invoking the rules via the alt+f3 menu (though I've no idea how or why, it just rans that dialog with some special parameter. Did you compare the detected values to those passed from the alt+f3 menu?) > So, the two FF's are working out of entirely separate directories Thats's irrelevant. The WM can distinguish it windows by some properties you can see in the matching dialog. To separate windows from same class and type, only role and title could be used for discrimination - where title is oc. rather dynamic wrt a browser (shows the current url) => please attach a kwinrulesrc with rules for both FF instances.
Okay. So I don't confuse matters. Working hard not to give you bad info: //KDE 4? => ~/.kde/share/config/kwinrulesrc// No, running 5. What I meant by empty is that I haven't made any window rules on that laptop yet (except by way of sussing out this bug). //Sounds like it's less a popup but more a normal window that is running into the focus stealing protecion?// That's above my pay grade: Can neither confirm nor deny. :) However! I think I've discovered the problem (or a workaround at least). XFCE4 Panel behaves as expected as long as I don't set it to "intelligently" hide. If "hide" is set to <always> or <never>, it functions as expected. If set to <intelligently> hide, I can't mouse click the panel (it will immediately disappear on clicking) unless the desktop is cleared. So... all this is probably a separate issue. Update on Second System: I was either wrong or the system (since updating to 15.10) no longer retains window rules (even when set via mouse right-clicking). The behavior on both systems is now the same. I can control the two instances of FF via ALTF3, separating them into their respective activities while the apps are running, but those preferences (as expected) are lost once the applications are closed. I cannot use "kcmshell5 kwinrules" to *permanently* assign them separate preferences. Plasma seems unable to recognize them as distinct instances of FF. If I set preferences for FF-A, then FF-B assumes those presets.
I am encountering this same issue, in kwin version: 4:5.6.5-0ubuntu1~ubuntu16.04~ppa1 STEPS TO REPRODUCE: 1. Right click any window titlebar 2. Select "more actions" 3a. Select "Special Window Settings..." OR 3b. Select "Special Application Settings..." 4a. Set "Activity" to "Apply Initially" to any individual Activity OR 4b. Set "Activity" to "Force" to any individual Activity 5. Click "OK" to save and close the Special Window/Activity Settings dialog 6. Repeat steps 1-3 to reopen the same dialog 7a. EXPECTED RESULT: "Activity" is set to "Apply Initially"/"Force" to the individual Activity specified in step 4. 7b. ACTUAL RESULT: "Activity" is set to "Apply Initially"/"Force" as specified in step 4, but to "All Activities" rather than the individual Activity selected in step 4. 8. Open the "System Settings application 9. Select "Window Behavior" 10. Select "Window Rules" 11. Open the Rule created in steps 1-5 12. Repeat steps 4-5, then step 11 13a. EXPECTED RESULT: "Activity" is set to "Apply Initially"/"Force" to the individual Activity specified in step 12. 13b. ACTUAL RESULT: "Activity" is set to "Apply Initially"/"Force" as specified in step 12, but to "All Activities" rather than the individual Activity selected in step 12.
Can reproduce steps in the description also in other CSD apps - Gnome Disks, Corebird in: Plasma: 5.12.3 Apps: 17.12.3 Frameworks: 5.44.0 Qt: 5.10.1 Kernel: 4.14.27-1-MANJARO OS: Netrunner Rolling
The menus seem to have changed in the mean time. I cannot reproduce the issue following the description. Can you please confirm, that it still persists with KDE 5.23 and provide an updated list of steps on how to reproduce?
(In reply to kde.org from comment #15) > The menus seem to have changed in the mean time. I cannot reproduce the > issue following the description. > Can you please confirm, that it still persists with KDE 5.23 and provide an > updated list of steps on how to reproduce? Not only have the menus changed, my back hurts, my children are all in college, and I no longer need to run separate instances of Firefox. That functionality is achieved with the Multi-Account Container Add-on. I no longer have the setup that produces this bug. It's an admittedly and exceedingly narrow use-case.
Thank you for your feedback! :-) Well, It hardly took 5 years for this result. Hope your children are doing well in college, your back gets better and you have a nice evening before the next week filled with hard work starts. I'll mark this as resolved, as we cannot reproduce the issue and the devs can spend their time on more actionable issue reports.