-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Description
The windows created by eframe on my system seem to not be able to detect their dimensions, which I noticed due to ViewportBuilder::with_min_inner_size not doing anything. (To potentially save time for people reading this, I suspect this is due to my somewhat bleeding-edge desktop environment, which I included details about below in the relevant section).
To Reproduce
Steps to reproduce the behavior:
- Put the following contents into the respective files:
# Cargo.toml
[package]
edition = "2021"
name = "scratch"
version = "0.1.0"
# This happens both on the latest published version and when depending directly on the latest master branch
[dependencies]
#eframe = "0.26.2"
eframe = { git = "https://github.com/emilk/egui", branch = "master" }# src/main.rs
use eframe::{egui::ViewportBuilder, NativeOptions};
fn main() {
eframe::run_simple_native(
"is this dark matter?",
NativeOptions {
viewport: ViewportBuilder::default().with_min_inner_size([1000.0, 1000.0]),
..Default::default()
},
|ctx, _| {
dbg!(ctx.used_size(), ctx.used_rect());
},
)
.expect("wait that wasn't supposed to be what went wrong...");
}-
cargo runorcargo run --release -
Check that the window is rendered properly
-
Check the print output and see the following:
[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
...Expected behavior
The dimensions reported by Context::used_rect and Context::used_size would be accurate (presumably positive, given that the window does seem to render fine) and the minimum size specified would be respected.
Screenshots
Desktop:
I suspect this might be where the issues lies; I'm using Plasma 6 from the Arch Linux testing repos, which only became available this week.
- OS: Linux (details from
unameshown below)
→ uname -a
Linux bunchacrunch 6.7.8-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Sun, 03 Mar 2024 00:30:23 +0000 x86_64 GNU/Linux
- Wayland (see attached output of
wayland-infofor details)
I'm unfortunately not sure what the best way to determine which rendering output is being used by eframe. I'm fairly certain that it's not using X11 because I generally can identify windows using XWayland by using wmctrl because it doesn't ever list info about native Wayland windows, and it similarly doesn't have any output related to the window opened by eframe. I'm not sure if it's using the wayland backend or glow (or if those are entirely different things rather than mutually exclusive options; I'm pretty inexperienced in programming GUIs).
Assuming this isn't reproducible easily on other desktops, I'm happy to add any additional info (either from my system or updating the repro code to print something else) that would be helpful to try to narrow cause what's causing this! If there's a different destkop environment that would be helpful for me to check, it shouldn't be too much of an issue; reverting back to Plasma 5 to test this would unfortunately be a bit of a pain given that I plan to keep using 6, but if there's no other way to sanity check things, I might be able to find an old laptop or something to boot up and try it out on that.
