Setting initial window size on GTK sets the wrong size

[hjmallon]

Describe the bug
I am using tao on weston with CentOS 9. Using the WindowBuilder with_inner_size doesn't seem to give the same inner_size.

Steps To Reproduce
I have attached an adjusted example from here to show this, just start it and press spacebar a few times.

Firstly it seems like inner_size and outer_size are always equal on Linux?

Expected behavior
with_inner_size(PhysicalSize::new(240, 240)) should make a window with a content area of 240x240. At the moment I get 240x277

Platform and Versions (please complete the following information):
OS: CentOS Stream 9, weston 8
Rustc: rustc 1.77.2

Additional context
It seems like I can work around this by setting the inner_size again after window decorations have been disabled.

// Copyright 2014-2021 The winit contributors
// Copyright 2021-2023 Tauri Programme within The Commons Conservancy
// SPDX-License-Identifier: Apache-2.0

use tao::{
  dpi::LogicalSize,
  event::{ElementState, Event, KeyEvent, WindowEvent},
  event_loop::{ControlFlow, EventLoop},
  keyboard::KeyCode,
  window::WindowBuilder,
};

#[allow(clippy::single_match)]
fn main() {
  env_logger::init();
  let event_loop = EventLoop::new();

  let window = WindowBuilder::new()
    .with_title("Test")
    .build(&event_loop)
    .unwrap();

  let mut time = 0;

  event_loop.run(move |event, _, control_flow| {
    *control_flow = ControlFlow::Wait;

    match event {
      Event::WindowEvent { event, .. } => match event {
        WindowEvent::CloseRequested => *control_flow = ControlFlow::Exit,
        WindowEvent::KeyboardInput {
          event:
            KeyEvent {
              physical_key: KeyCode::Space,
              state: ElementState::Released,
              ..
            },
          ..
        } => {
          println!("inner_size: {:?}, outer_size: {:?}, scale_factor: {}", window.inner_size(), window.outer_size(), window.scale_factor());

          if time == 0 {
            println!("window.set_inner_size(LogicalSize[width: 240, height: 240])");
            window.set_inner_size(LogicalSize{width: 240, height: 240});
          } else if time == 1 {
            println!("window.set_decorations(true)");
            window.set_decorations(true);
          } else if time == 2 {
            println!("window.set_inner_size(LogicalSize[width: 240, height: 240])");
            window.set_inner_size(LogicalSize{width: 240, height: 240});
          } else if time == 3 {
            println!("window.set_decorations(false)");
            window.set_decorations(false);
          } else if time == 4 {
            println!("window.set_inner_size(LogicalSize[width: 240, height: 240])");
            window.set_inner_size(LogicalSize{width: 240, height: 240});
          }

          time = time + 1
        }
        _ => ()
      },
      _ => (),
    };
  });
}

[hjmallon]

I can reproduce the problem on Gnome Wayland on Fedora I think. I think the problem is that hiding decorations after setting the internal_size doesn't change the size which was allocated for the titlebar. When setting up stuff from the window builder it works in that order, size then decorations.

[yuezk]

I encountered this problem with Gnome Wayland on Ubuntu 24.04. Use the example in the wry repo by setting the inner_size to LogicalSize::new(240.0, 240.0).

cargo run --example simple

My test indicates that it breaks since tao 0.30.3. I added logs around the following code and found that the size differs after the show_all method is called in 0.30.3

tao/src/platform_impl/linux/window.rs

Lines 227 to 231 in d0e46ad

	if attributes.visible {
	window.show_all();
	} else {
	window.hide();
	}

Bellow is the test result with tao 0.30.3

I tested the code changes in #984 and found that it fixed this problem visually (I mean, while the webview size is correct, the logged size is incorrect for both width and height).

Rolling back to 0.30.2 can get the correct size for both the visual and logged sizes. However, the window cannot move (this could be the problem tauri-apps/tauri#10686).