Skip to content

Fix/fractional scaling and tiling bugs#589

Open
ScherbakovAl wants to merge 5 commits into
domferr:mainfrom
ScherbakovAl:fix/fractional-scaling-and-tiling-bugs
Open

Fix/fractional scaling and tiling bugs#589
ScherbakovAl wants to merge 5 commits into
domferr:mainfrom
ScherbakovAl:fix/fractional-scaling-and-tiling-bugs

Conversation

@ScherbakovAl

Copy link
Copy Markdown

Problem

Since GNOME 49, fractional scaling (logical monitor layout mode) is enabled by
default on Wayland and is no longer listed in mutter's experimental-features.
The extension therefore assumed it was disabled and applied the monitor scale
factor on top of the compositor's own scaling. At 150% scale this made the
indicator menu, snap assistant, layout editor and tile previews 1.5x too big
(the menu did not even fit the screen) and the window border too thick and
misplaced.

While debugging this, I also found a few unrelated tile geometry bugs.

Fractional scaling fixes

  • Add isFractionalScalingEnabled() helper that treats fractional scaling as
    enabled on GNOME 49+ Wayland sessions (with a fallback to
    XDG_SESSION_TYPE, since Meta.is_wayland_compositor() was removed in
    newer GNOME versions).
  • Fix inverted enableScaling flag when recreating WindowBorderManager on
    experimental-features changes.
  • Gate the snap assistant threshold and the overridden window menu scaling on
    actual scaling support instead of applying the monitor scale factor
    unconditionally.

Tile geometry fixes

  • findNearestTile used source.x for the y coordinate of the window
    center, selecting a wrong tile when moving across monitors.
  • Missing parentheses in the "best tile" distance computation in auto-tiling
    and in the overridden window menu.
  • Use innerGaps.top (instead of .right twice) when enlarging the search
    area for keyboard-driven tiling.
  • Use ?? instead of || for the monitor index fallback, so monitor 0 is not
    mistaken for the primary monitor.

UI fixes

  • Wrap the editor dialog's layouts row in a horizontal St.ScrollView so the
    dialog fits the screen with many layouts or low resolutions (mouse wheel
    scrolls horizontally).
  • Give the preferences window a proper default size (720x940, clamped to 90%
    of the monitor size) instead of opening smaller than its content.

Tested only on my own setup: GNOME Shell 50.3, Fedora, Wayland, with
fractional scaling. Other configurations (X11, older GNOME versions) were not
tested — review of the version-gated paths is appreciated.

** Generated by Fable 5. I hope the corrections are correct.

ScherbakovAl and others added 5 commits July 19, 2026 01:04
Since GNOME 49, fractional scaling (logical monitor layout mode) is
enabled by default on Wayland and is no longer listed in mutter's
experimental-features, so the extension wrongly assumed it was disabled
and applied the monitor scale factor on top of the compositor's own
scaling. At 150% this made the indicator menu, snap assistant, layout
editor and tile previews 1.5x too big (the menu did not fit the screen)
and the window border too thick and misplaced.

- add isFractionalScalingEnabled() helper that treats fractional
  scaling as enabled on GNOME 49+ Wayland sessions
- fix inverted enableScaling flag when recreating WindowBorderManager
  on experimental-features changes
- gate the snap assistant threshold and the overridden window menu
  scaling on the actual scaling support instead of applying the monitor
  scale factor unconditionally
- fix findNearestTile using source.x for the y coordinate of the
  window center, selecting a wrong tile when moving across monitors
- fix missing parentheses in the "best tile" distance computation in
  auto-tiling and in the overridden window menu
- consider innerGaps.top (instead of .right twice) when enlarging the
  search area for keyboard-driven tiling
- use ?? instead of || for the monitor index fallback so monitor 0 is
  not mistaken for the primary monitor

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Since GNOME 49, fractional scaling (logical monitor layout mode) is
enabled by default on Wayland and is no longer listed in mutter's
experimental-features, so the extension wrongly assumed it was disabled
and applied the monitor scale factor on top of the compositor's own
scaling. At 150% this made the indicator menu, snap assistant, layout
editor and tile previews 1.5x too big (the menu did not fit the screen)
and the window border too thick and misplaced.

- add isFractionalScalingEnabled() helper that treats fractional
  scaling as enabled on GNOME 49+ Wayland sessions
- fix inverted enableScaling flag when recreating WindowBorderManager
  on experimental-features changes
- gate the snap assistant threshold and the overridden window menu
  scaling on the actual scaling support instead of applying the monitor
  scale factor unconditionally
- fix findNearestTile using source.x for the y coordinate of the
  window center, selecting a wrong tile when moving across monitors
- fix missing parentheses in the "best tile" distance computation in
  auto-tiling and in the overridden window menu
- consider innerGaps.top (instead of .right twice) when enlarging the
  search area for keyboard-driven tiling
- use ?? instead of || for the monitor index fallback so monitor 0 is
  not mistaken for the primary monitor

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- use ?? instead of || for the monitor index fallback in EditorDialog,
  same fix as in defaultMenu, so monitor 0 is not mistaken for the
  primary monitor
- wrap the layouts row in a horizontal St.ScrollView so the dialog fits
  the screen when there are many layouts or the resolution is low;
  mouse wheel scrolling is mapped to the horizontal axis

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The preferences window opened smaller than its content, forcing the
user to resize it. Set a 720x940 default size, clamped to 90% of the
monitor size so it still fits low resolution screens.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant