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

Setting initial window size on GTK sets the wrong size #929

Open
hjmallon opened this issue May 17, 2024 · 2 comments · May be fixed by #984
Open

Setting initial window size on GTK sets the wrong size #929

hjmallon opened this issue May 17, 2024 · 2 comments · May be fixed by #984

Comments

@hjmallon
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

yuezk commented Dec 10, 2024

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

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

Bellow is the test result with tao 0.30.3

image

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

image

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

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants