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.

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

gnome-text-editor doesn't allow resizing when run under X11 #3560

Open
RAOF opened this issue Aug 20, 2024 · 5 comments
Open

gnome-text-editor doesn't allow resizing when run under X11 #3560

RAOF opened this issue Aug 20, 2024 · 5 comments
Labels
bug triaged Triage into JIRA to plan it in XWayland

Comments

@RAOF
Copy link
Contributor

RAOF commented Aug 20, 2024

Pretty much as title. env -u WAYLAND_DISPLAY gnome-text-editor --standalone on Oracular results in a gnome-text-editor window that doesn't show resize handles on the edge of its window. It can be manually resized (for example, with +middle-button drag on miral-shell).

@RAOF
Copy link
Contributor Author

RAOF commented Aug 23, 2024

Aha! This is probably at least partially because we don't render the whole window - you can see in these screenshots that we're clipping off the dropshadow surrounding the gnome-text-editor window in XWayland (it's correct using the Wayland backend), and GTK only shows the resize handles when over the drop-shadow!

Screenshot of gnome-text-editor X11 showing the obvious corners of drop shadow

Screenshot of gnome-text-editor Wayland including drop shadows

@AlanGriffiths
Copy link
Contributor

X11 isn't "the future" so forcing GTK to use X11 is perverse and not a usecase we need care about, especially the resizing.

I'm more interested in whether trimming the dropshadow on X11 apps is a good idea. (And if it is intentional)

@tarek-y-ismail
Copy link
Contributor

tarek-y-ismail commented Sep 6, 2024

X11 isn't "the future" so forcing GTK to use X11 is perverse and not a usecase we need care about, especially the resizing.

I'm more interested in whether trimming the dropshadow on X11 apps is a good idea. (And if it is intentional)

The issue isn't exclusive to GTK apps, it occurs on any application using CSD decorations on X11. For example, on IntelliJ IDEA (see #3570), on QT when using the built-in corner resizing widget (probably chrome too? edit: chrome doesn't?!).

Chris and I discussed this and fixing the dropshadow issue might also fix resizing, but I've yet to find the root cause.

@AlanGriffiths
Copy link
Contributor

I see the logic in trimming dropshadow with SSD, but it is not so clear with CSD as they may be part of the client logic (and, if so, that might help with resize).

You may get some insight from --window-management-trace as that will show:

  1. if the window manager even gets a resize request; and, if so,
  2. the circumstances when the resize request gets cancelled

@tarek-y-ismail
Copy link
Contributor

tarek-y-ismail commented Sep 6, 2024

Ok, so trying a native Wayland window (kgx) vs IntelliJ IDEA shows that there's not much difference in the events. Themselves except the following snippet, more specifically the action=motion part which pops up a lot for kgx but very little for IDEA:

[2024-09-06 17:39:30.820501] <information> miral::Window Management: handle_pointer_event event={from=3, action=motion, button_state=1, x=390, y=777, dx=0, dy=1, vscroll=0, hscroll=0, modifiers=1}
[2024-09-06 17:39:30.820640] <information> miral::Window Management: info_for -> tarek@y540: ~/code-projects/mir
[2024-09-06 17:39:30.820784] <information> miral::Window Management: modify_window window_info={name=tarek@y540: ~/code-projects/mir, type=freestyle, state=restored, top_left=320, 178, size=(831, 595), children={}, min_width=360, min_height=294, exclusive_rect=0, preferred_orientation=0xf, confine_pointer=0}, modifications={top_left=320, 178, size=(831, 596)}
[2024-09-06 17:39:30.820880] <information> miral::Window Management: advise_resize window_info={name=tarek@y540: ~/code-projects/mir, type=freestyle, state=restored, top_left=320, 178, size=(831, 595), children={}, min_width=360, min_height=294, exclusive_rect=0, preferred_orientation=0xf, confine_pointer=0}, new_size=(831, 596)

Of course, gnome-text-editor still doesn't initiate resizes, but moving the cursor outside of it sends a bunch of events to set the min width/height, and clicking inside (moving doesn't do anything) also sends these events. I'm not sure if they're related to the problem but it seems redundant to send that unnecessarily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug triaged Triage into JIRA to plan it in XWayland
Projects
None yet
Development

No branches or pull requests

3 participants