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

[Zamoca42]

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.

   

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.

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.

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.

Conclusion

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

[github-actions]

Package Changes Through 77b40c2

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

[amrbashir]

Thank you

[amrbashir]

Actually after a second test, there is a few things I noticed:

1. 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)

2. 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

[Zamoca42]

• 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]

resizing here makes the window create with a smaller size than expected, and then after a brief moment, it will jump into the requested size

Previously, the header’s title affected the inner size, which made the size appear to jump.

before.mov

I added an event to prevent the title from affecting the inner size.

after.mov

Additionally, the number of title characters displayed is updated when the window is resized based on its width.

resize.mov

[amrbashir]

I can still see the size changes, see this gif

[Zamoca42]

Sorry, I was unable to reproduce the issue.
The only potentially suspicious part I can think of is the priority when creating a new window, so I’ve tried setting all related priorities to a higher level.
Could you check if this makes a difference?

[yuezk]

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 tauri-apps/tauri#10686 (comment), 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.