You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gnome Shell version: 45.5
Extension version: 58 (67 most likely affected too)
Setup: 1080p laptop with a 4K monitor connected as primary
Expected result: top panel is blurred across the full width at session start
Actual result: top panel is blurred only to the laptop screen's width at session start
While investigating the issue, I noticed that one of the child actors has the width param set to 1920.
If I toggle the panel blur or the entire extension, everything works correctly (as show in the ER screenshot).
I found that in the current implementation, find_monitor_for() returns an incorrect monitor at session start.
However, the v67 approach w/ findMonitorForActor() works the same way (I made similar adjustments in v58 and tested).
Below is a workaround patch that I'm currently using to overcome the issue.
Nevertheless, I'm not sure whether this solution is optimal, and most likely there are some caveats I may have missed.
Please share your thoughts.
The mentioned patch:
diff --git a/src/components/panel.js b/src/components/panel.js
index 0a335b5..2921b9d 100644
--- a/src/components/panel.js
+++ b/src/components/panel.js
@@ -145,7 +145,7 @@ export const PanelBlur = class PanelBlur {
panel_box = panel_box.get_parent();
}
- let monitor = this.find_monitor_for(panel);
+ let monitor = Main.layoutManager.primaryMonitor;
if (!monitor)
return;
@@ -247,7 +247,7 @@ export const PanelBlur = class PanelBlur {
actors.widgets.background = is_static
? new Meta.BackgroundActor({
meta_display: global.display,
- monitor: this.find_monitor_for(actors.widgets.panel).index
+ monitor: Main.layoutManager.primaryMonitor.index
})
: new St.Widget;
@@ -317,7 +317,7 @@ export const PanelBlur = class PanelBlur {
if (this.settings.panel.STATIC_BLUR) {
let bg = Main.layoutManager._backgroundGroup.get_child_at_index(
Main.layoutManager.monitors.length
- - this.find_monitor_for(actors.widgets.panel).index - 1
+ - Main.layoutManager.primaryMonitor.index - 1
);
if (bg && bg.get_content())
actors.widgets.background.content.set({
@@ -332,7 +332,7 @@ export const PanelBlur = class PanelBlur {
let panel = actors.widgets.panel;
let panel_box = actors.widgets.panel_box;
let background = actors.widgets.background;
- let monitor = this.find_monitor_for(panel);
+ let monitor = Main.layoutManager.primaryMonitor;
if (!monitor)
return;
@@ -362,23 +362,7 @@ export const PanelBlur = class PanelBlur {
}
// update the monitor panel is on
- actors.monitor = this.find_monitor_for(panel);
- }
-
- /// An helper function to find the monitor in which an actor is situated,
- /// there might be a pre-existing function in GLib already
- find_monitor_for(actor) {
- let extents = actor.get_transformed_extents();
- let rect = new Mtk.Rectangle({
- x: extents.get_x(),
- y: extents.get_y(),
- width: extents.get_width(),
- height: extents.get_height(),
- });
-
- let index = global.display.get_monitor_index_for_rect(rect);
-
- return Main.layoutManager.monitors[index];
+ actors.monitor = Main.layoutManager.primaryMonitor;
}
/// Connect when overview if opened/closed to hide/show the blur accordingly
The text was updated successfully, but these errors were encountered:
Gnome Shell version: 45.5
Extension version: 58 (67 most likely affected too)
Setup: 1080p laptop with a 4K monitor connected as primary
Expected result: top panel is blurred across the full width at session start
Actual result: top panel is blurred only to the laptop screen's width at session start
While investigating the issue, I noticed that one of the child actors has the width param set to 1920.
If I toggle the panel blur or the entire extension, everything works correctly (as show in the ER screenshot).
I found that in the current implementation,
find_monitor_for()
returns an incorrect monitor at session start.However, the v67 approach w/
findMonitorForActor()
works the same way (I made similar adjustments in v58 and tested).Below is a workaround patch that I'm currently using to overcome the issue.
Nevertheless, I'm not sure whether this solution is optimal, and most likely there are some caveats I may have missed.
Please share your thoughts.
The mentioned patch:
The text was updated successfully, but these errors were encountered: