Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hard to resize windows when using CSD #3427

Closed
slrtbtfs opened this issue Mar 29, 2021 · 37 comments
Closed

Hard to resize windows when using CSD #3427

slrtbtfs opened this issue Mar 29, 2021 · 37 comments
Labels
bug

Comments

@slrtbtfs
Copy link

Describe the bug
When using the client side Wayland decorations (see #3284), grabbing one of the bottom corners of the window to resize it requires pixel perfect positioning of the mouse pointer to be able to change both width and height of the window.

To Reproduce
Steps to reproduce the behavior:

  1. Use the client side decorations.
  2. Try to grab one of the bottom corners to resize the terminal window.
  3. Unless you positioned the pointer very precisely you will actually have grabbed an edge of the window.

Expected behavior
There should be some tolerance for grabbing those corners, i.e. if the pointer is a few pixels off it should still work.

Screenshots
If applicable, add screenshots to help explain your problem.

Unfortunately, GNOME Screenshots don't capture the pointer, so getting a meaningful screenshots here doesn't work.

Environment details
OS: Fedora 34 / GNOME 40

kitty 0.19.3 created by Kovid Goyal
Linux 5.11.9-300.fc34.x86_64+debug #1 SMP Wed Mar 24 11:47:06 UTC 2021 x86_64
\S
Kernel \r on an \m (\l)
Loaded config files: /home/slrtbtfs/.config/kitty/kitty.conf
Running under: Wayland

Config options different from defaults:
background              Color(red=30, green=30, blue=30)
color0                  Color(red=58, green=60, blue=67)
color1                  Color(red=190, green=62, blue=72)
color10                 Color(red=14, green=113, blue=46)
color11                 Color(red=195, green=112, blue=51)
color12                 Color(red=23, green=108, blue=227)
color13                 Color(red=251, green=0, blue=103)
color14                 Color(red=45, green=111, blue=108)
color15                 Color(red=252, green=255, blue=184)
color2                  Color(red=134, green=154, blue=58)
color3                  Color(red=196, green=165, blue=53)
color4                  Color(red=78, green=118, blue=161)
color5                  Color(red=133, green=91, blue=141)
color6                  Color(red=86, green=142, blue=163)
color7                  Color(red=184, green=188, blue=185)
color8                  Color(red=136, green=137, blue=135)
color9                  Color(red=251, green=0, blue=30)
cursor                  Color(red=248, green=61, blue=25)
font_family             Comic Code Ligatures
font_size               12.0
foreground              Color(red=184, green=188, blue=185)
linux_display_server    wayland
open_url_modifiers      2
selection_background    Color(red=41, green=44, blue=49)
selection_foreground    Color(red=30, green=30, blue=30)
strip_trailing_spaces   smart
tab_bar_edge            1
tab_bar_style           powerline
touch_scroll_multiplier 5.0
window_padding_width    FloatEdges(left=2.0, top=2.0, right=2.0, bottom=2.0)

Additional context
Try to reproduce the problem with kitty --config NONE if you cannot then post a minimal kitty.conf that reproduces the problem. If the problem involves interaction with some other terminal program post a minimal config for that program to reproduce the problem as well.

linux_display_server wayland
@slrtbtfs slrtbtfs added the bug label Mar 29, 2021
@kovidgoyal
Copy link
Owner

This is already fixed in the csd branch, where the window decorations
are made wider.

@slrtbtfs
Copy link
Author

Ah, thanks! I just tried out that branch and this particular issue seems to be fixed there.

However I found a few other issues when using that branch, but I assume that's because it's still WIP.

I'll be happy to test it again and report whatever issues I find, as soon as you consider it ready for external input.

@kovidgoyal
Copy link
Owner

Feel free to pint out any issues you notice. I am, at best, peripherally
interested in CSD, so it will receive minimal testing from me.

@slrtbtfs
Copy link
Author

I am, at best, peripherally interested in CSD.

Well, thanks for working on it anyway, then.

Here are some things I noticed.

  • Compiling with GCC 11.0.1 fails, clang 12.0.0 compiles fine.

  • The completely white decorations are invisible, when the window is in front of a white background.
    image

  • the hide_window_decorations configuration options doesn't do anything.

  • The behavior of hiding the side and bottom window decorations when the window isn't focused looked a bug at first, but the commit messages hint that this might be intended behavior. If this is kept, maybe it shouldn't be default behavior.

  • Since the CSDs are probably mainly going to be used with GNOME, it might make sense to use a similar style than GNOME Terminal, i.e. very thin borders combined with shadows and rounded corners:

GNOME Terminal focused:
image

GNOME Terminal unfocused:

image

@kovidgoyal
Copy link
Owner

kovidgoyal commented Apr 1, 2021 via email

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 1, 2021

Fails with what error?

This one 

Compiling [wayland] glfw/wl_client_side_decorations.c ...
gcc -MMD -DNDEBUG -D_GLFW_WAYLAND -D_GLFW_BUILD_DLL -DHAS_MEMFD_CREATE -Wextra -Wfloat-conversion -Wno-missing-field-initializers -Wall -Wstrict-prototypes -std=c11 -pedantic-errors -Werror -O3 -fwrapv -fstack-protector-strong -pipe -march=native -fvisibility=hidden -D_FORTIFY_SOURCE=2 -fPIC -flto -fPIC -pthread -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -c glfw/wl_client_side_decorations.c -o build/glfw-wayland-wl_client_side_decorations.c.o
glfw/wl_client_side_decorations.c: In function ‘free_csd_surfaces’:
glfw/wl_client_side_decorations.c:122:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:5: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |     ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:122:78: note: in expansion of macro ‘decs’
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |                                                                              ^~~~
glfw/wl_client_side_decorations.c:125:5: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |     ^
glfw/wl_client_side_decorations.c:123:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:5: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |     ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:123:69: note: in expansion of macro ‘decs’
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |                                                                     ^~~~
glfw/wl_client_side_decorations.c:125:5: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |     ^
glfw/wl_client_side_decorations.c:122:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:14: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |              ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:122:78: note: in expansion of macro ‘decs’
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |                                                                              ^~~~
glfw/wl_client_side_decorations.c:125:14: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |              ^
glfw/wl_client_side_decorations.c:123:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:14: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |              ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:123:69: note: in expansion of macro ‘decs’
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |                                                                     ^~~~
glfw/wl_client_side_decorations.c:125:14: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |              ^
glfw/wl_client_side_decorations.c:122:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:22: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                      ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:122:78: note: in expansion of macro ‘decs’
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |                                                                              ^~~~
glfw/wl_client_side_decorations.c:125:22: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                      ^
glfw/wl_client_side_decorations.c:123:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:22: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                      ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:123:69: note: in expansion of macro ‘decs’
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |                                                                     ^~~~
glfw/wl_client_side_decorations.c:125:22: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                      ^
glfw/wl_client_side_decorations.c:122:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:32: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                                ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:122:78: note: in expansion of macro ‘decs’
  122 |     if (decs.which.subsurface) wl_subsurface_destroy(decs.which.subsurface); decs.which.subsurface = NULL; \
      |                                                                              ^~~~
glfw/wl_client_side_decorations.c:125:32: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                                ^
glfw/wl_client_side_decorations.c:123:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |     ^~
glfw/wl_client_side_decorations.c:125:32: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                                ^
glfw/wl_client_side_decorations.c:15:14: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   15 | #define decs window->wl.decorations
      |              ^~~~~~
glfw/wl_client_side_decorations.c:123:69: note: in expansion of macro ‘decs’
  123 |     if (decs.which.surface) wl_surface_destroy(decs.which.surface); decs.which.surface = NULL; \
      |                                                                     ^~~~
glfw/wl_client_side_decorations.c:125:32: note: in expansion of macro ‘d’
  125 |     d(left); d(top); d(right); d(bottom);
      |                                ^
cc1: all warnings being treated as errors
make: *** [Makefile:9: all] Error 1

I suppose adding a gradient would be easy enough.

A solid light gray would work, too. Thats what alacritty does.

Why would anyone want to do this for only one
window type in their system?

I mainly tried this option out, since the empty decorations weren't really useful. But I won't use that option, when CSDs work properly.

That's a placeholder, ideally colors should change.
Ah, then that makes sense.

Just re-implement render_edge() to render the shadow to an ARGB bitmap.

Thanks for the hint. I might look into that, but I won't get to it until in a few weeks or so.

@kovidgoyal
Copy link
Owner

This work has been merged to master. Titles are now displayed, and the
color has been changed to be a bit darker.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 1, 2021 

commit eb3a2126ee3fa7a2dbeebb4d86fa9b4ea85b5080
Author: Kovid Goyal <[email protected]>
Date:   Thu Apr 1 22:57:19 2021 +0530

    Changelog entry for CSD work

    Bloody two days of my life I will never get back thanks to those
    *&^(*&%*%*& at GNOME.

Well, thanks for going trough that pain anyway!

@kovidgoyal
Copy link
Owner

Well, I learned a bit more about wayland, so not totally a waste. And to be fair 75% of the stuff in kitty I dont use personally anyway.

@kovidgoyal
Copy link
Owner

Note that I added support for shadows. Please test, things seem to work fine in mybrief testing on GNOME. The quality of the shadows could possibly be improved by playing with the gaussian parameters, I leave that as an exercise to the reader.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 6, 2021

Oh, thanks.

I tried it out today and while the shadows are fine, there seems to be a newly introduced bug that resizes the window when it is tiled to the left and then unfocused.

I think the screencast explains it better than words could:

Screencast.from.04-06-2021.01.54.00.PM.mp4

@kovidgoyal
Copy link
Owner

Doesnt repro for me, do you have some steps I can try. Also I doubt this
has anything to do with shadows, more likely: 7e78f30

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 6, 2021 •
edited
Loading

I git bisected the issue and 3e2b626 was the commit that ended up being blamed:

3e2b626107d7fcf55213399dab57f109c745e1b4 is the first bad commit
commit 3e2b626107d7fcf55213399dab57f109c745e1b4
Author: Kovid Goyal <[email protected]>
Date:   Mon Apr 5 09:10:47 2021 +0530

    Inform compositor of visible window geometry

    The numbers dont make logical sense, but they do what is expected on
    GNOME and since only GNOME is stupid enough to insist on CSD, that's
    all we care about.

 glfw/wl_client_side_decorations.c | 16 ++++++++++++++++
 glfw/wl_client_side_decorations.h |  1 +
 glfw/wl_window.c                  | 10 ++--------
 3 files changed, 19 insertions(+), 8 deletions(-)

Regarding reproduction:

  1. Open kitty and some other window, both unmaximized.
  2. Drag the kitty window to the left screen edge, so GNOME/mutter (in my case GNOME 40) will resize the window to use the left half of the screen.
  3. Click to focus the other window.
  4. Kitty now resizes to its previous vertical height, which it shouldn't.

@kovidgoyal
Copy link
Owner

Those steps dont reproduce for me, fee free to play with the numbers its line 401-403 in wl_client_side_decorations.c since you can repro maybe you can figure out what the numbers should be. If that is indeed the problem then simply commenting out line 405 will fix it, but then gnome will treat the shadows as part of the window for positioning purposes.

@kovidgoyal
Copy link
Owner

See is this fixes it: f849f38

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 6, 2021

Nope, that doesn't fix it.

I tried to debug the issue myself and it turned out, that the height and width parameters passed to xdgToplevelHandleConfigure are wrong when the undesired resizes happen. They used to be correct before 3e2b626 .
What I haven't figured is why.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 6, 2021

See is this fixes it: f849f38

But with that commit the upper half of the top decoration isn't visible when the window is maximized, since it's positioned a bit too high.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 6, 2021

And it turns out the kitty window also umaximizes itself when I first maximize it and then switch to another window. I guess that's the same underlying problem.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 6, 2021

The documentation for xdg_surface_set_window_geometry says:

   * Once the window geometry of the surface is set, it is not possible to
   * unset it, and it will remain the same until set_window_geometry is
   * called again, even if a new subsurface or buffer is attached.

My best guess is that some of the handling necessary when tiling/maximizing is done by the compositor, until that function is first called. After that, kitty has to do it itself, which it possibly didn't do so far.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Apr 7, 2021 via email

@kovidgoyal
Copy link
Owner

kovidgoyal commented Apr 7, 2021 via email

@kovidgoyal
Copy link
Owner

This looks like a bug in GNOME. Add a printf() to line 428 in
wl_window.c

    printf("maximized: %d fullscreen: %d activated: %d width: %d height: %d\n", maximized, fullscreen, activated, width, height);

and you will see the compositor sending configure events with new sizes
to kitty every time focus is switched away from the window or switched
back to it.

It does this for me even when the window is not maximized/tiled and
kitty does not call set_window_geometry at all. I dont really see what
I can do here.

And I was wrong earlier, the xdg_toplevel spec apparently implements tiled
window states as well in addition to fullscreen. Probably need to hide
the shadows in all those states.

@kovidgoyal
Copy link
Owner

Aaah, I think I figured it out. From the docs for the configure event

 * The states listed in the event specify how the width/height
 * arguments should be interpreted, and possibly how it should be
 * drawn.

Am guessing GNOME expects windows to interpret the width and height as
either including the shadows or not depending on whether the window is
focused/tiled/maximized/fullscreen.

Such a poorly thought out mechanism, typical for Wayland. It isnt
documented anywhere I could find, and could potentially vary between
compositors. Le sigh. Fortunately, only GNOME is stupid enough to
require all these shenanigans, so I guess one can just figure out
empirically what GNOME wants and do that when drawing CSD.

@kovidgoyal
Copy link
Owner

Should be fine now. At least on my system I cant see any problems. Switching focus does not change the window size. GNOME seems to get the correct content area size for the window, as can be verified by moving the mouse to the top left corner of the screen to trigger window selection mode, then hovering over the kitty window and observing that the window selection border is correctly drawn over the content area excluding the shadows.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 7, 2021

Add a printf() to line 428 in
wl_window.c

That's more or less what I did yesterday.

Such a poorly thought out mechanism, typical for Wayland.

I'm beginning to understand why you hate it.

And I was wrong earlier, the xdg_toplevel spec apparently implements tiled
window states as well in addition to fullscreen.

Well, the spec declares those tiled states, wayland-xdg-shell-client-protocol.h, generated by wayland-scanner does, too.

However, wayland-xdg-shell-client-protocol.c, also generated by wayland-scanner, apparently doesn't implement the code for handling those particular states, while stuff like maximizing is handled there. At least thats how it doesn't work on my system.

This looks like a bug in GNOME.

I guess it is. I also couldn't find any applications that implement shadows without using cairo or GTK, so maybe they're just not worth it.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 7, 2021

Oh, and I forgot to mention that the resizing issue still persist for me, even with the latest commits.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 7, 2021

Some debug logs, comment (using #) with what would have been the right configure events.

top-level configure event: size: 0x0 states:
final window content size: 977x815
GL version string: '4.6 (Core Profile) Mesa 21.0.1' Detected version: 4.6
top-level configure event: size: 977x839 states: TOPLEVEL_STATE_ACTIVATED
final window content size: 977x815
top-level configure event: size: 977x839 states:
final window content size: 977x815
top-level configure event: size: 977x839 states: TOPLEVEL_STATE_ACTIVATED
final window content size: 977x815
[097 15:50:31.014789] No render frame received in 0.25 seconds
# This should have included a tiled state
top-level configure event: size: 1280x1400 states: TOPLEVEL_STATE_ACTIVATED
# This is reported wrong by kitty. Moving the respective debug() statement down two lines gives a correct number.
final window content size: 977x815
# Now the unfocus happens. The size sent by the compositor is just wrong
top-level configure event: size: 989x851 states:
final window content size: 1280x1376
top-level configure event: size: 989x851 states: TOPLEVEL_STATE_ACTIVATED
final window content size: 989x827
[097 15:50:48.999765] No render frame received in 0.25 seconds
top-level configure event: size: 1280x1400 states: TOPLEVEL_STATE_ACTIVATED
final window content size: 989x827
top-level configure event: size: 1280x1400 states: TOPLEVEL_STATE_ACTIVATED
final window content size: 1280x1376
top-level configure event: size: 977x839 states: TOPLEVEL_STATE_ACTIVATED
final window content size: 1280x1376
# Maximizing and unfocusing the window gives similar results.
top-level configure event: size: 2560x1400 states: TOPLEVEL_STATE_MAXIMIZED TOPLEVEL_STATE_ACTIVATED
final window content size: 977x815
top-level configure event: size: 989x851 states: TOPLEVEL_STATE_MAXIMIZED
final window content size: 2560x1376

@kovidgoyal
Copy link
Owner

Hmm am at a loss. I made one final commit, which should prevent the size changing in dispatchChngesAfterConfigure() maybe that will help. 82a5733 but without being able to reproduce... BTW what scale are you using, my system has scale = 2 it maybe we are seeing different behavior because of that, only thing I can think of.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 7, 2021

BTW what scale are you using

Right now scale=1, when I have an additional screen, scale=1 on one an scale=2 on another screen.

What version of GNOME are you using?

I'll try to use an older version, to see if it's a newly introduced GNOME bug.

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 7, 2021

I tried with scale=2 and the bug still exists there.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Apr 7, 2021 via email

@kovidgoyal
Copy link
Owner

kovidgoyal commented Apr 7, 2021 via email

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 7, 2021

Does it happen with only a single monitor?

Yes.

40.0.0

I use the same version. So using an older one probably won't help.

@kovidgoyal
Copy link
Owner

Hmm, well I am at a loss...

@kovidgoyal
Copy link
Owner

Interestingly I just updated my system, GNOME version according to the
about dialog is still 40.0.0 but now I can reproduce. So definitely
seems like a regression in GNOME.

@kovidgoyal
Copy link
Owner

Easy enough to workaround the regression in GNOME once I could
reproduce. 4e6d5d3

@slrtbtfs
Copy link
Author

slrtbtfs commented Apr 8, 2021

Interestingly I just updated my system, GNOME version according to the
about dialog is still 40.0.0 but now I can reproduce.

Maybe it was a mutter update.

Anyway, great that it works now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kovidgoyal @slrtbtfs