[Bug] DPI changes and window controls not re-scaling

[luispabon]

I'm running unite in Pop 19.04. This laptop has a 4k screen, and I run it at scale 2. Unite shows the window controls in the panel just fine.

The problem is when I connect a second, non hidpi monitor and the hidpi daemon compensates by changing the laptop to 1080p and scale 1:

Conversely, if gnome and unite load up initially at scale 1 cause I have external monitors connected, and then I disconnect them and the laptop screen goes back to 4K, the opposite happens (window controls way too small).

[budzynski]

+1

Also, quick mitigation for the time being: Alt + F2, type "r", and hit Enter. It will refresh the Gnome Shell and fix the buttons' scale.

[jonian]

Can you try in changing in https://github.com/hardpixel/unite-shell/blob/master/unite%40hardpixel.eu/modules/windowButtons.js#L27:

// From this
this._signals.connect(this.monitorManager, 'monitors-changed', 'toggleButtons')

// To this
this._signals.connect(this.monitorManager, 'monitors-changed', 'updateButtons')

[budzynski]

Didn't resolve the problem.

Another interesting thing (lazy render?) - if I don't hover over the buttons on the first screen, then switch to another screen, and hover over the buttons on the new screen - the hovered buttons' size is correct.

[plumlis]

Same here
My laptop has 4K diskplay and I using it with 200% scaling.
Sometimes I use it with 1080p monitor and set scaling to 100%
After I changed scaling, the windows control buttons ( Max Min Close) won't auto scale to the correct size, It looks sooo big or sooo small.
I have to restart gnome-shell to slove this. (Alt+F2 and type R)

[plumlis]

Is there a workaround for this issue?
I'm now on wayland, and There is no way to restart gnome-shell.

[plumlis]

Any news about this issue？

[jonian]

@plumlis The issue is tagged as help-wanted because I don't have a hidpi screen to work on this.

[plumlis]

@jonian Thanks for your reply.

Actually you don't really need a HiDPI to test about this issue, You can do these step like this:

• set your display scale to 200%
• install and enable Unite extension
• set your display scale back to 100%
• And you will see window controls buttons still 200% scaled, Just like image in the top post

The Main issue seems is window controls buttons don't change with display Scaling

By the way, I'm glad to help you with my HiDPI Display.

[ilya-m32]

Hey, recently learned about this extension - great stuff, really enjoy it! Many thanks to the authors.

In Ubuntu 23.04, Gnome Shell=44.0 and unite-shell=71 the issue seems to remain unresolved.
I also confirm that steps to reproduce are the same as in the previous comment: #106 (comment)

I made few quick experiments with the code and seems that buttons once rendered are preserved in the same scale factor, even if the Btn element is re-created due to layout change.

Then, I decided to try St.Icon widget instead of using background-image: url('some_file.svg') for window controls and it seems to be working fine - it perfectly adapts for different scaling factors like 1x / 2x / 3x.

I made a small demo theme which works this way and adapts to different scale factors. Here's the commit (see screenshots for 2x/1x scaling factor).

My guess is that there might be a gnome-shell bug related to re-scaling background-image svg once rendered - no proofs, though, I also don't know much about gnome-shell architecture.

I have some ideas about validating this hypothesis and possible workaround, will try it out a bit later.

[JoveYu]

any update?

[ilya-m32]

I played with the issue a little bit and it seems to be a gnome bug apparently; none of the ways I tried to force redraw worked.

Due to limited time, I just switched to my ad-hoc theme using St.Icon default icons which works fine and you can find it in my fork. Probably worth reporting this bug to gnome folks.

If anyone wants this, I can create a PR to the upstream with this theme.

[ilya-m32]

I reported the issue to the Gnome team, let's see how it goes.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6824

[ilya-m32]

No updates from gnome shell team but I found a workaround: #356
Feel free to join discussion there