In the course of improving the display dialog to support extended desktop mode, I realized that the panel currently doesn't support RandR's "primary monitor" setting. Instead, the panel always sits on the left-most monitor (i.e. the one that has x:0,y:0).
I think this would be a nice feature to implement along the display-dialog improvements, then it'd make sense to add a "make primary" checkbox to the dialog to move the panel.
A workaround consist in adding a udev rule triggered on monitor connection / disconnection and modifying xfce4-panel monitor using
xfconf-query -c xfce4-panel -p /panels/panel-0/output-name -s LVDS1
You can find complete solution here :
But I would prefer this issue be solved using "primary monitor settings" described by Simon Steinbeiss.
here is a primitive patch to chose the "Primary" monitor if "Automatic" is selected as the output.
diff --git a/panel/panel-window.c b/panel/panel-window.c
index c21aac3..1d371ca 100644
@@ -2013,9 +2013,10 @@ panel_window_screen_layout_changed (GdkScreen *screen,
+ /* get the primary monitor */
+ monitor_num = gdk_screen_get_primary_monitor (screen);
/* get the monitor geometry based on the panel position */
- monitor_num = gdk_screen_get_monitor_at_point (screen, window->base_x,
gdk_screen_get_monitor_geometry (screen, monitor_num, &a);
panel_return_if_fail (a.width > 0 && a.height > 0);
diff --git a/panel/panel-window.h b/panel/panel-window.h
index f5aa603..e1de633 100644
@@ -33,6 +33,11 @@ typedef struct _PanelWindow PanelWindow;
#define PANEL_IS_WINDOW(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), PANEL_TYPE_WINDOW))
#define PANEL_IS_WINDOW_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), PANEL_TYPE_WINDOW))
#define PANEL_WINDOW_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), PANEL_TYPE_WINDOW, PanelWindowClass))
+/* workaround to get "primary" monitor on gtk versions older than 2.20.0 */
+#if !GTK_CHECK_VERSION (2, 20, 0)
+#define gdk_screen_get_primary_monitor(screen) (gdk_screen_get_monitor_at_point (screen, window->base_x, window->base_y))
GType panel_window_get_type (void) G_GNUC_CONST;
I've done a quick test of this and it works well, definitely better than what we have now. I'd second merging this.
*** Bug 8936 has been marked as a duplicate of this bug. ***
I have noted a possible bug, my panel is being stretched out of the current screen when I remove the external monitor, not sure why yet. I hope to dig through and see if the "old" code is being used elsewhere. Some where that works out the screen length?
(In reply to RichTea from comment #5)
> I have noted a possible bug, my panel is being stretched out of the current
> screen when I remove the external monitor, not sure why yet. I hope to dig
> through and see if the "old" code is being used elsewhere. Some where that
> works out the screen length?
So you're sure this is a regression?
Seems a bit odd to me because if you disconnect the secondary monitor the result from both gdk_screen_get_primary_monitor and gdk_screen_get_monitor_at_point should be 0.
Maybe add some debug output to that portion of the code to see what happens when you disconnect the monitor.
Sorry for the delay, I blieave what is happing is "our" value for the screen geometry is not being updated when the extra monitors are being removed, so the bar ends up to long.
Just trying to understand where that is!
OK after a little digging it seems its a bug with my X session not with Panel or this update.
So the Diff Stands as it was...
Is there something holding up this patch?
I came here with the same issue. Ended up figuring out the GUI panel move myself via https://forum.xfce.org/viewtopic.php?pid=35746#p35746
This problem has been bugging people for years [1,2,3,4]. RichTea provided a patch which apparently fixes the issue, at least for the panel. Can you please merge it?
What's holding me (or I guess anyone else with push-rights) back is that the panel's target is now Gtk3, there are no more feature-releases planned for the current Gtk2 panel.
So this patch would have to be ported on top of Gtk3 so we could merge it: https://git.xfce.org/users/andrzejr/xfce4-panel/log/?h=gtk3
+(In reply to Simon Steinbeiss from comment #11)
> What's holding me (or I guess anyone else with push-rights) back is that the
> panel's target is now Gtk3, there are no more feature-releases planned for
> the current Gtk2 panel.
> So this patch would have to be ported on top of Gtk3 so we could merge it:
Porting to GTK3 would involve using gdk_display_get_primary_monitor as gdk_screen_get_primary_monitor is deprecated. It should still be trivial to do if one has a development environment and dependencies for the GTK3 branch of the panel set up (which I don't). There's also a "nick/gtk3" branch in the official repo, not sure what the difference is to the andrzejr one.
Also, this should be considered a bug fix, not a feature. Even the GDK documentation clearly states,
> While normal application windows typically allow the window manager to place the windows, specialized desktop applications such as panels should place themselves on the primary monitor.
So this should be merged into the GTK2 version now, and in the GTK3 version too whenever that's released. Unless there's a reason to stay with the old behaviour, which many users (and the GDK docs) consider broken.
Created attachment 6996
I agree, this is a bug in the code not an enhancement, I have attached a patch file with a workaround for any one running older versions of GTK (<2.20) maybe a similar a workaround to this can be used for GTK3!.
The work around is a little icky, maybe instead there should be an xfce function created "xcfe_get_primary_monitor" that could chose the appropriate backed gtk function depending on the gtk version being used.
Created attachment 7033
Add option for supporting primary monitor
I have reworked the original patch a little and made "Primary" an additional option. I'm not sure I like changing the "Automatic" behavior or dropping it in favor of the "Primary" option.
This means that we can later also add a check - if necessary - to check for older versions of XRandR which don't support the "primary" feature.
Finally, I've rebased the patch on top of git master, which is now the Gtk3 port of the panel.
Please give it some testing.
I'd love to see this feature in release soon. I am really surprised that xfce-panel ignores the primary-flag in xrandr. My three-monitor-setup includes my primary display as the center monitor now, but my panel stays on the leftmost monitor. This is not expected behaviour, at least for me.
Pushed to master: https://git.xfce.org/xfce/xfce4-panel/commit/?id=a24b0214c9218ab39581d0e40b1b441913d631f7
This means the feature will be part of the 4.13 (development) and 4.14 (stable) releases.
I will evaluate whether we can backport this easily in a regression-free manner to 4.12.
Sounds great, thanks!
Thanks Simon and RichTea for this fix. I really would like to get it in my environment. I had to switch to another desktop environment until this issue is fixed. Is there a way to build 4.13 myself, or at least build 4.12 and apply the patch myself? I'm using xubuntu with XFCE 4.12.
I have finally found the time to backport this to 4.12. Please test from my branch:
(In reply to Simon Steinbeiss from comment #20)
> I have finally found the time to backport this to 4.12. Please test from my
I applied 18df47092db and everything seems to be working.
However, I am seeing the same bug I've had with the previous patch by RichTea. If only 2 of 3 defined monitors are active, part of the third panel will be sitting at the top of the screen (i.e. a 1 or 2 pixels high line is visible). It might be related to the authide function, which is enabled for this panel.
(In reply to haarp from comment #21)
> However, I am seeing the same bug I've had with the previous patch by
> RichTea. If only 2 of 3 defined monitors are active, part of the third panel
> will be sitting at the top of the screen (i.e. a 1 or 2 pixels high line is
> visible). It might be related to the authide function, which is enabled for
> this panel.
Could you please either share your panel setup via xfpanel-switch or describe the setup in detail so I can try to reproduce?
(In reply to Simon Steinbeiss from comment #22)
> Could you please either share your panel setup via xfpanel-switch or
> describe the setup in detail so I can try to reproduce?
All panels are horizontal and at the bottom.
Panel 1: full length, always visible, on Primary output
Panel 2: 75% length, autohide enabled, Monitor 1
Panel 3: 75% length, autohide enabled, Monitor 2
I have three monitor setups (it's a laptop)
Mobile: laptop screen
Home: laptop screen left, primary monitor right
Work: laptop screen left, primary monitor middle, 2nd monitor right
At work things work as expected.
On mobile, I can see panel 2 hiding behind panel 1 (they're partially transparent) - but I understand why. panel 2 is set to monitor 1 after all :) It seems it always counts them from left to right.
At home things get weird. on the laptop screen, I can partially see one of the 75% panels the *top* of the laptop screen (a 1 or 2 pixels wide bar is sticking out). This happens even if both monitors are set to mirror, but not if the monitor is unplugged.
I can provide the xfconf config if necessary.
I think the bug I'm seeing is unrelated to this patch and is a general issue with xfce4-panel's output handling. Therefore I've made a new report at bug 13831.
Primary output is working as intended (tested in 4.13.1) and I think this can be closed. Thanks!
Ok, thanks for testing again. Closing this report then.
Simon Steinbeiss referenced this bugreport in commit cc453ea2402167d48ddff8da75fd026e3c2dc26e
Add support for XRandR's primary monitor feature (Bug #9338)
I'm preparing a new release for 4.12 with the primary feature now (since the translations are fixed now). Waiting for translations to trickle in and then there'll be a maintenance release.
Created attachment 7392
make 'Primary' the default output
I think the implementation is incomplete. Please consider applying the attached patch on top.
Created attachment 7393
make 'Automitic' the default selection for output
... or the other way round.
I amended your second patch a little (panel_str_is_empty does not exist on the 4.12 branch) and pushed it. Thanks for catching that!