Description of problem: I have two monitors with two panels, each is set to "live" on one monitor and each has a "Window Buttons" applet set to show only windows present on that monitor. This works fine until When I disconnect/re-connect secondary monitor; after that which the panel on the secondary monitor only shows the windows from the primary one. Version-Release number of selected component (if applicable): xfce4-panel-4.10.1-3.fc20.x86_64 How reproducible: always on this machine Steps to Reproduce: 0. Have two monitors, say A as primary and B as secondary 1. Set up two panels, each bound to one monitor 2. On each panel, add "Windows Buttons" 3. In both applets' settings, uncheck "Show windows from all monitors" * now each applet should only list windows currently present on that monitor 4. Open some windows on both panels (better have them have different titles) 5. Disconnect and re-connect the secondary monitor (on my Thinpkad T430s sleep/wake works as well) 6. In case windows from monitor B have been moved to A, move them back 7. Observe the panel on monitor B Actual results: The panel lists only windows from monitor A. (At this point windows from B are not listed anywhere) Expected results: Panel should behave the same as before reconnecting or sleep/wake. Additional info: To restore desired behavior, it's sufficient to open the applet on window B and check/un-check the mentioned check-box.
Sorry, > until When I disconnect/re-connect secondary monitor and > 5. Disconnect and re-connect the secondary monitor (on my Thinpkad T430s > sleep/wake works as well) is incorrect. I've yet to specify exactly how this happens but it's actually more to do with restarting and changing layout manually (including rotation. The situation is that from previous layout I have this (see attachment 848255 [details]): ~ amahdal@fullmoon:~$ cat .screenlayout/nb-below-monitor.sh #!/bin/sh xrandr --output DP3 --off --output DP2 --off --output DP1 --off --output HDMI3 --mode 1920x1080 --pos 0x0 --rotate normal --output HDMI2 --off --output HDMI1 --off --output LVDS1 --mode 1600x900 --pos 112x1080 --rotate normal --output VGA1 --off amahdal@fullmoon:~$ ~ but later I rotated the larger monitor to "portrait" right to the laptop and since I'm "lazy" to update above file, I always change it with arandr after reboot+login. The bug is introduced somewhere in that process.
So, this is a pretty detailed case. Thanks. ;) However, I don't have multi-monitor setup here to easily debug it. Would you be willing to file this upstream at bugzilla.xfce.org? If you prefer I could as well, but since you have the setup to test with it might be better if you do so.
Kevin I knew you would ask that and I'll be happy to do it, but I wanted to play with this more so that I have better idea of how to reproduce (since I already it's not actually the steps in comment 0). So thanks for reminding this to me, it was starting to slowly but dangerously sink on my TODO list :) ~ So I have played with this problem a little with new user accounts, and I think I know how to reproduce it. It's probably combination of two issues though, not both of them in xfce4-panel. So: * When I open ARandR using desktop file, change settings and use "Apply", settings are not permanent, i.e. restored on next login. If you open ARandR from Xfce's settings manager, the layout is saved/restored on next login. Note that use of Save/Load functionality of ARandR is irrelevant here, these settings just convenient scripts to be launched e.g. by .xsessionrc or a key binding. They are not hooked anywhere by default. (Trivia: I have been setting the layout after login each time for about 9 months before realizing (now) it's actually possible/supposed to have the settings saved and restored. I thought it's just how it works and did not care since I hardly ever re-logged so it did not really bother me.) * So what's reported here happens if you 1. save a layout by launching ARandR from Settings Manager 2. then log out and back in 3. and finally open ARandR using a desktop file and change layout again. That's when the Windows Buttons' settings stop working correctly. ~ So now I'm going to file the first issue separately (or search for it), and then the second one to the Xfce4 upstream, with proper reproducers and cross-references. Stay tuned... :)
The problem with ARandR/Xfce4 settings manager has been reported to our tracker as bug 1071935. The original issue has been reported upstream[1] (with updated reproducer): [1]: https://bugzilla.xfce.org/show_bug.cgi?id=10725
Thanks! Added myself to cc upstream too...
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Can't test this now, but since the upstream issue has not been fixed (only slightly improved, maybe), I'm moving it to rawhide to dodge EOL.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.