tao icon indicating copy to clipboard operation
tao copied to clipboard

fix(wayland): fix the inaccurately applied inner_size when creating a new window.

Open Zamoca42 opened this issue 1 year ago • 4 comments

Fixes #929

Reproduce

  1. When setting with_inner_size to 300 x 300 and running with cargo run --example window, a window size discrepancy occurs, resulting in 300 x 261.

    window box
  2. The size of the window border is 45px on KDE Wayland, and it’s the same for all apps.

  3. This is because the window border is included in the inner_size value, causing a mismatch when window.resize().

The 39px discrepancy in height is due to the inclusion of the titlebar’s height.

스크린샷 2024-09-28 오후 11 41 07

Changes

Added width and height settings to the window box properties corresponding to the inner size. Added a height property to the header so that it is included in the window border, not the inner_size.

See: https://blog.gtk.org/2019/03/27/layout-managers-in-gtk-4/

Additional Context

In Tao’s Linux window box properties, width_request = -1, height_request = -1 is passed, and when resized to the min_size, the internal window size changes to include the window borders.

  • min_height = 200,
  • box allocation_height = 70 + 45(border) + 85(border + titlebar_height) = 200.
스크린샷 2024-09-29 오후 8 04 38 스크린샷 2024-09-29 오후 7 42 28

Compared with the Firefox app on KDE Wayland.

In Firefox, the properties are set with values other than -1 for size_request, so when reduced to size, the inner window size does not include the border values.

스크린샷 2024-09-28 오후 11 22 28 스크린샷 2024-09-29 오후 7 12 39 스크린샷 2024-09-29 오후 7 11 51

Conclusion

To prevent inaccurate inner_size, we need to set size_request and configure the width and height values in the window properties.

Zamoca42 avatar Sep 29 '24 11:09 Zamoca42

Package Changes Through 77b40c2e4ed010af63a5f2b94666cda261da5da0

There are 1 changes which include tao with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package current next
tao 0.30.5 0.30.6

Add another change file through the GitHub UI by following this link.


Read about change files or the docs at github.com/jbolda/covector

github-actions[bot] avatar Sep 30 '24 22:09 github-actions[bot]

Thank you

amrbashir avatar Sep 30 '24 22:09 amrbashir

  • if you launch the app and cursor is out of the window (i.e the eventloop doesn't recieve any events) the whole window size will be 300x300, once you move the mouse inside the window, it will jump into a bigger size (352x399)
  • if I create a window with 300x300 inner size, then window.inner_size should report the same size later on, I think this is a problem in dev as well though

Thank you for your review. After testing the window example on GNOME + Wayland, I found that the event loop fetches the size of the top layout, GtkApplicationWindow (352 x 399), instead of the inner size. If the event loop is intended to receive the inner size rather than the window size including decorations, I believe we need to modify it to fetch the size of its child (GtkBox).

As a side note, I previously mentioned that the total size of the app includes a border width of 45px, but that applies to KDE. I have confirmed that on GNOME, the default border width is 26px.

Zamoca42 avatar Oct 01 '24 05:10 Zamoca42

Hi guys,

Thanks for your great work on this project. I encountered this problem and want to have a discussion about it.

By referring to the comments on https://github.com/tauri-apps/tauri/issues/10686#issuecomment-2325240664, the Hello World application seems to work on Wayland OOTB.

Why must we use the hack solution (by introducing a custom header on Wayland) to fix the moving problem? Is it possible that we are using the wrong API?

I'm totally new to the Tao system, above is just my humble opinion.

yuezk avatar Dec 10 '24 09:12 yuezk