On MacOS when moving a window between monitors of different resolutions the window appears fine until a resize event. When a resize event happens the scaling is off in my case by either 1/2 or 2x depending on whether I'm moving between hi res to low res or the other way around. I haven't been able to find where the problem is originating from.

My initial guess was that the display scale was set once upon window creation and then used later because the window always resizes properly on the resolution that it was created on but has issues when it is moved to a different resolution. But I couldn't find anything in the code that looked like it was caching the scale

It might be nice to have a simple list UI element for easily displaying small numbers of elements.
Similar to like you might use label for simple text, but use rich_text for more intricate display.

It would also be nice to let the simple list automatically compute element size, if that is possible. One annoyance with virtual list is having to know your element size beforehand.

Example use case:
A handful of predetermined tab headers that should just be automatically sized + positioned based on their container's width + padding.

See CursorStyle::Text

The readme says Inspired by Xilem, Leptos and rui .

First, a Thank-you to developers for your contribution towards open-source rust gui renderer.

Please create a doc/featmatrix.md file with the following information in detail, and link it in to the readme.
What a user would like to know

• What design choices are different, tradeoffs, and how they affect a final rendering?
• What each choice does and does not do (as of today)?
• How should a user choose between alternatives ?

On a related note, one also needs a up-to-date API documentation, functional call, arguments etc.

I've read Levien's blogs (https://raphlinus.github.io/), He may not have touched as much on floem. but you should also write a comprehensive and self-contained write-up, even if it repeats some of his observations.

Seems like vger (best guess) doesn't render border radii correctly on HiDPI screens. Rounded rectangles look correct on my external display but on my MacBook built in display the corners aren't rounded properly

Glazier seems to have numerous issues on Linux.

1. Default backend is X11. This is a problem for many reasons:
   a. x11 is unmaintained and no-longer the default graphics session on many distributions
   b. it then runs through XWayland, which causes further issues (root cause of #16 )
2. It can't be compiled with both X11 and Wayland due to the way it imports items within itself.
3. The wayland backend currently segfaults (on gnome due to linebender/glazier#81)

I don't know if you want to continue on with glazier - winit is a solid alternative. Or maybe make floem window-management agnostic? Either way the inability to support both x11 and wayland is problematic where wayland should be the default with a fallback to x11.

As it stands the only possible way to run examples or lapce/floem branch on hybrid GPU linux systems is to offload to the dGPU (increasing power use considerably).

Description:

On riscv64 platforms, we are able to successfully compile and run wgpu. However, due to issues with the compilation of tiny_skia, we are unable to utilize it fully.

Steps to Reproduce:

1. Clone the repository on a riscv64 machine.
2. Run the build command specific to wgpu.
3. Observe that while wgpu compiles successfully, the build fails due to tiny_skia.

Expected Behavior:

The build should succeed and we should be able to run wgpu-only functionality on riscv64.

Actual Behavior:

The build fails due to tiny_skia compilation issues, preventing us from using wgpu-only functionality.

Additional Information:

It would be beneficial to have a feature flag that allows us to force the use of wgpu-only, bypassing the tiny_skia dependency.

Possible Solution:

Introduce a feature flag that when enabled, excludes tiny_skia from the build process, allowing for wgpu-only operation.

Child views should update dynamically in response to signal changes.

Eg.

fn wave_options(wave_type: ReadSignal<WaveType>) -> impl View {
    container_box(move || match wave_type.get() {
        WaveType::WaveSelect => Box::new(default_wave_options()),
        WaveType::CustomFunction => Box::new(custom_function()),
    })
    .style(|| Style::BASE.flex_col().width_pct(100.))
}

One thing to note though is that because the views are strongly typed any place where the child changes dynamically the possible children must all be of the exact same view type (which includes all children). Using BoxContainer would be necessary in any cases where the children weren't exactly the same.

I tried implementing this on BoxContainer but kept running into issues

pub fn container_box(child: impl Fn() -> Box<dyn View> + 'static) -> ContainerBox {
    let cx = ViewContext::get_current();
    let id = cx.new_id();
    let mut curr_cx = cx;
    curr_cx.id = id;
    ViewContext::save();
    ViewContext::set_current(curr_cx);
    create_effect(cx.scope, move |_| {
        let child_id = curr_cx.new_id();
        let mut child_cx = curr_cx;
        child_cx.id = child_id;
        ViewContext::save();
        ViewContext::set_current(child_cx);
        let new_child = child();
        id.update_state(new_child, false);
        ViewContext::restore();
    });
    ViewContext::restore();
    let (_temp_child_id, temp_child) = ViewContext::new_id_with_child(crate::views::empty);
    ContainerBox {
        id,
        child: Box::new(temp_child),
    }
}

This is probably not the right approach. I run into issues with the ids. Inside of the effect I always get a mutable borrow error when creating the new id.

Is there a different way I should be approaching this?

If a text_input isn't marked as keyboard_navigatable it can't be edited and seems like it can't gain focus.

When using position absolute elements don't include the size of absolutely position elements. This makes it so that elements that are absolutely positioned and in a list will have whether they are rendered be completely dependent on the parent element. So if an element is position absolutely below its parent the entire element will disappear as soon as the parent is scrolled out of view even though the child was still in view

Given the this code:

use floem::{
    reactive::create_rw_signal,
    view::View,
    views::{container, h_stack, label, Decorators},
    widgets::text_input,
};

fn app_view() -> impl View {
    let text = create_rw_signal("".to_string());

    container(
        h_stack((
            label(move || String::from("Hello world")).style(|s| s.width(100)),
            text_input(text).style(|s| s.width_full()),
        ))
        .style(|s| s.flex_row().width_full().items_center().justify_center()),
    )
    .style(|s| s.width_full().padding(10))
}

fn main() {
    floem::launch(app_view);
}

You get this:

Here is a gif of the issue:

As you can see at first before entering any text into the input field I can resize the window freely without blowouts.
As soon as I input text the text input seems to get a fixed min size even after I remove the text inputted earlier.

I am building a GUI app that contains an input field which I am trying to give the ability to clear when someone clicks on an x symbol.

I reduced my code the the simplest view below:

use floem::{
    reactive::create_rw_signal,
    style::{AlignContent, AlignItems, CursorStyle, Display, Position},
    view::View,
    views::{container, container_box, h_stack, label, svg, Decorators},
    widgets::text_input,
};

fn app_view() -> impl View {
    let search_icon = r##"<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" fill="#424242">
        <path fill-rule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zM8.28 7.22a.75.75 0 00-1.06 1.06L8.94 10l-1.72 1.72a.75.75 0 101.06 1.06L10 11.06l1.72 1.72a.75.75 0 101.06-1.06L11.06 10l1.72-1.72a.75.75 0 00-1.06-1.06L10 8.94 8.28 7.22z" clip-rule="evenodd" />
    </svg>"##;

    let search_text = create_rw_signal("".to_string());

    h_stack((
        label(|| String::from("Search / Create:")).style(|s| {
            s.font_size(12.0)
                .padding(3.0)
                .padding_top(8.0)
                .padding_left(10.0)
        }),
        container_box(text_input(search_text).keyboard_navigatable().style(|s| {
            s.padding(5.0)
                .z_index(1)
                .width_full()
                .margin(3.0)
                .padding_right(30.0)
                .border_radius(2)
        }))
        .style(|s| s.width_full().z_index(1)),
        container(svg(move || search_icon.to_string()).style(|s| {
            s.z_index(6)
                .inset_top(7)
                .inset_right(4)
                .height(16.0)
                .width(16.0)
                .cursor(CursorStyle::Pointer)
        }))
        .on_click_stop(move |_| {
            search_text.set(String::from(""));
        })
        .style(move |s| {
            s.position(Position::Absolute)
                .height(30.0)
                .width(30.0)
                .display(Display::None)
                .align_items(AlignItems::Baseline)
                .align_content(AlignContent::Center)
                .padding_left(10.0)
                .z_index(5)
                .inset_top(0)
                .inset_right(3)
                .cursor(CursorStyle::Pointer)
                .hover(|s| s.cursor(CursorStyle::Pointer))
                .apply_if(!search_text.get().is_empty(), |s| s.display(Display::Flex))
        }),
    ))
    .style(|s| s.width_full().height(30.0))
}

fn main() {
    floem::launch(app_view);
}

This will compile something like this (on macos):

When you type something into the input the symbol appears:

The inspector view of this layout:

This pattern has exposed three issues I will try my best to detail below:

1. The cursor not being respected on top of another element with a cursor directive

Unfortunately because it's over-layed above the text input the cursor shows the input cursor and not the Pointer as I declared in the code.

2. The bounding box of the area you can actually type in is significantly smaller than it seems

When you type you can only type to an arbitrary weird length:

3. It crashes sometimes

When I type something, then clear it with a click on the icon and then continue to type without clicking anything (in this case the letter s) it crashes. I assume because the focus is still on the symbol which is now being hidden with display: none?

The error is:

thread 'main' panicked at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/alloc/src/string.rs:1538:9:
assertion failed: self.is_char_boundary(idx)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:377:33:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }

Hope this helps

Outline style, similar to the css style property. This could be used for the focus visible style, to avoid shifting the layout. This CSS tricks article explains the difference between borders and outlines.

Have just discovered Floem (via This Week in Rust) and have been looking at the examples.

Problem:
None of the examples paint their UIs upon startup (at least on my system).
The winit window frame is displayed but the window content is just whatever was on screen behind the window when it opened.
The only action that triggers the UI to start painting itself is resizing the window.
Via the Counter example I can observe that I can click on the buttons that are not visible (the console reports when the counter is reset). These application state changes do not trigger the UI to paint itself.
Once the window has been resized to trigger the first paint of the UI the examples work as intended.

Environment
rustc: 1.73.0 - stable-x86_64-unknown-linux-gnu
Operating System: Arch Linux
KDE Plasma Version: 5.27.9
Kernel Version: 6.6.1-arch1-1 (64-bit)
Graphics Platform: X11
Graphics Processor: NVIDIA GeForce GTX 1080

Please let know what else I can do to assist solving this problem.

Thanks.

It would be good to have an easy way to have things happen on hover.
Implementation Suggestions:
AppState can have a hover: Vec<Id> which is just a list of all the currently hovered views.
ViewState Can get a hover_style: Option<Style> (or just Style::default()) which is then applied in fill_reified_style, if the element is hovered.

Then needs some code to detect when the mouse enters

let rect = cx.get_size(self.id).unwrap_or_default().to_rect();
if rect.contains(event.pos) {

and set hover, and clear reified style cache
And some code to detect when the mouse leaves, removing it from the hover list if it is in there and clearing reified style cache.
Unsure where that logic should go.

When items are given position absolute the items that should be underneath them just render on the "same layer". They just overlap each other. Background's don't cover up other elements and the "top" element stops receiving events.

Hey love this project! 🤙

Is it possible to remove the closures from views to reduce the syntax noise? I'm assuming it's sometimes useful to use a closure, like for nested state, but I think those cases could use view::from_fn where we could impl View for some FromFn type

It would nice to have a method to draw text at any angle. Some UIs have text running along the side, like left tabs.
I'm not sure if cosmic text supports this automatically?

views styled with position absolute that render on top of other views by using a z_index do not get prioritized events

https://github.com/AccessKit/accesskit

Hi!

As a lazy dev I would like to slap a kind of stylesheet to my UI to get started with a beautiful UI. Is that something that should be handled by third party component libs?

WSL introduced support for graphical applications some time ago. Attempting to run any of the examples fails:

$ cargo run -p counter
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Requesting a device failed', src/renderer.rs:18:89
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Requesting a device failed

Stack backtrace:
   0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
             at /home/jp/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.71/src/error.rs:547:25
   1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/result.rs:1961:27
   2: floem_vger::VgerRenderer::new
             at ./vger/src/lib.rs:43:31
   3: floem::renderer::Renderer::new
             at ./src/renderer.rs:18:13
   4: floem::context::PaintState::connect
             at ./src/context.rs:1000:30
   5: <floem::app_handle::AppHandle<V> as glazier::window::WinHandler>::connect
             at ./src/app_handle.rs:802:9
   6: glazier::backend::x11::window::Window::connect::{{closure}}
             at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:533:13
   7: glazier::backend::x11::window::Window::with_handler_and_dont_check_the_other_borrows
             at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:521:31
   8: glazier::backend::x11::window::Window::with_handler
             at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:512:9
   9: glazier::backend::x11::window::Window::connect
             at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:532:9
  10: glazier::backend::x11::window::WindowBuilder::build
             at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:455:9
  11: glazier::window::WindowBuilder::build
             at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/window.rs:547:9
  12: floem::app::Application::window::{{closure}}
             at ./src/app.rs:84:26
  13: leptos_reactive::runtime::RuntimeId::run_scope_undisposed
             at /home/jp/.cargo/registry/src/index.crates.io-6f17d22bba15001f/leptos_reactive-0.3.1/src/runtime.rs:461:10
  14: leptos_reactive::scope::Scope::run_child_scope
             at /home/jp/.cargo/registry/src/index.crates.io-6f17d22bba15001f/leptos_reactive-0.3.1/src/scope.rs:160:13
  15: leptos_reactive::scope::Scope::child_scope
             at /home/jp/.cargo/registry/src/index.crates.io-6f17d22bba15001f/leptos_reactive-0.3.1/src/scope.rs:137:29
  16: floem::app::Application::window
             at ./src/app.rs:68:17
  17: floem::app::launch
             at ./src/app.rs:9:5
  18: counter::main
             at ./examples/counter/src/main.rs:88:5
  19: core::ops::function::FnOnce::call_once
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/ops/function.rs:250:5
  20: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/sys_common/backtrace.rs:135:18
  21: std::rt::lang_start::{{closure}}
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:166:18
  22: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/ops/function.rs:284:13
  23: std::panicking::try::do_call
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:500:40
  24: std::panicking::try
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:464:19
  25: std::panic::catch_unwind
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panic.rs:142:14
  26: std::rt::lang_start_internal::{{closure}}
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:148:48
  27: std::panicking::try::do_call
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:500:40
  28: std::panicking::try
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:464:19
  29: std::panic::catch_unwind
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panic.rs:142:14
  30: std::rt::lang_start_internal
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:148:20
  31: std::rt::lang_start
             at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:165:17
  32: main
  33: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  34: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:392:3
  35: _start', src/renderer.rs:18:89
stack backtrace:
   0:     0x56392dba2da1 - std::backtrace_rs::backtrace::libunwind::trace::hd8505f8952b1d578
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x56392dba2da1 - std::backtrace_rs::backtrace::trace_unsynchronized::he70ad17ef2414299
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x56392dba2da1 - std::sys_common::backtrace::_print_fmt::h81c1ab30de355b1d
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/sys_common/backtrace.rs:65:5
   3:     0x56392dba2da1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hb173052fee9a48be
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x56392dbd0def - core::fmt::rt::Argument::fmt::h24bdb8fc1cdd6ab9
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/fmt/rt.rs:138:9
   5:     0x56392dbd0def - core::fmt::write::hfb27016af2bf9db2
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/fmt/mod.rs:1094:21
   6:     0x56392db9eaf7 - std::io::Write::write_fmt::hdbf39a1cb4978ec7
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/io/mod.rs:1714:15
   7:     0x56392dba2bb5 - std::sys_common::backtrace::_print::h2b230e23e6fe9050
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x56392dba2bb5 - std::sys_common::backtrace::print::hdb8675132c4d8f36
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x56392dba40e3 - std::panicking::default_hook::{{closure}}::h0083d1f8688099c0
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:269:22
  10:     0x56392dba3e74 - std::panicking::default_hook::he0b85b7a539a4b82
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:288:9
  11:     0x56392dba46d9 - std::panicking::rust_panic_with_hook::hade3b16f8984a4e1
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:705:13
  12:     0x56392dba45d7 - std::panicking::begin_panic_handler::{{closure}}::hfe9b4aa9f3378108
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:597:13
  13:     0x56392dba3206 - std::sys_common::backtrace::__rust_end_short_backtrace::h853639dc488abc88
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/sys_common/backtrace.rs:151:18
  14:     0x56392dba4322 - rust_begin_unwind
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:593:5
  15:     0x56392dbcd933 - core::panicking::panic_fmt::h35d15b5e11fdd4fa
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/panicking.rs:67:14
  16:     0x56392dbcdec3 - core::result::unwrap_failed::ha412526979475a54
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/result.rs:1651:5
  17:     0x56392c801f9d - core::result::Result<T,E>::unwrap::h56c0c310f7a5eb9c
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/result.rs:1076:23
  18:     0x56392c8272fa - floem::renderer::Renderer::new::h463009c282d0d570
                               at /home/jp/dev/floem/src/renderer.rs:18:13
  19:     0x56392c820dc2 - floem::context::PaintState::connect::h3368eac8ce9dd1c1
                               at /home/jp/dev/floem/src/context.rs:1000:30
  20:     0x56392c78ef00 - <floem::app_handle::AppHandle<V> as glazier::window::WinHandler>::connect::h102831e5854294c7
                               at /home/jp/dev/floem/src/app_handle.rs:802:9
  21:     0x56392ce53691 - glazier::backend::x11::window::Window::connect::{{closure}}::ha38ea3c0988109e9
                               at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:533:13
  22:     0x56392ce51b6c - glazier::backend::x11::window::Window::with_handler_and_dont_check_the_other_borrows::hf15488772beaafd4
                               at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:521:31
  23:     0x56392ce3a726 - glazier::backend::x11::window::Window::with_handler::h8d9a6513d837db19
                               at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:512:9
  24:     0x56392ce535f7 - glazier::backend::x11::window::Window::connect::h071d839d23005c65
                               at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:532:9
  25:     0x56392ce34158 - glazier::backend::x11::window::WindowBuilder::build::hc31499371551c992
                               at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/backend/x11/window.rs:455:9
  26:     0x56392cf1633e - glazier::window::WindowBuilder::build::h583728f6303d9a0d
                               at /home/jp/.cargo/git/checkouts/glazier-b8f821eee8f52b00/ab692f5/src/window.rs:547:9
  27:     0x56392c787f72 - floem::app::Application::window::{{closure}}::hea3484618d9b9ece
                               at /home/jp/dev/floem/src/app.rs:84:26
  28:     0x56392c7864d9 - leptos_reactive::runtime::RuntimeId::run_scope_undisposed::h1865324e54d8d9ad
                               at /home/jp/.cargo/registry/src/index.crates.io-6f17d22bba15001f/leptos_reactive-0.3.1/src/runtime.rs:461:10
  29:     0x56392c7864d9 - leptos_reactive::scope::Scope::run_child_scope::h83ff7cfbb0461ab9
                               at /home/jp/.cargo/registry/src/index.crates.io-6f17d22bba15001f/leptos_reactive-0.3.1/src/scope.rs:160:13
  30:     0x56392c7864d9 - leptos_reactive::scope::Scope::child_scope::h9d426c0675b616ac
                               at /home/jp/.cargo/registry/src/index.crates.io-6f17d22bba15001f/leptos_reactive-0.3.1/src/scope.rs:137:29
  31:     0x56392c7864d9 - floem::app::Application::window::hd730778169f3492c
                               at /home/jp/dev/floem/src/app.rs:68:17
  32:     0x56392c78815c - floem::app::launch::ha087c6e4a6452f82
                               at /home/jp/dev/floem/src/app.rs:9:5
  33:     0x56392c77a406 - counter::main::h914dc085e4c68845
                               at /home/jp/dev/floem/examples/counter/src/main.rs:88:5
  34:     0x56392c77801b - core::ops::function::FnOnce::call_once::h3afbb712c954cc74
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/ops/function.rs:250:5
  35:     0x56392c788e7e - std::sys_common::backtrace::__rust_begin_short_backtrace::he42a7af143e9940f
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/sys_common/backtrace.rs:135:18
  36:     0x56392c753c61 - std::rt::lang_start::{{closure}}::hdccb72b722852e7c
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:166:18
  37:     0x56392db998fb - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hf8da20fcdbafddaf
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/core/src/ops/function.rs:284:13
  38:     0x56392db998fb - std::panicking::try::do_call::h2eefd2c69a7fe1d9
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:500:40
  39:     0x56392db998fb - std::panicking::try::h4465d987fce1dcd2
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:464:19
  40:     0x56392db998fb - std::panic::catch_unwind::hb3f183be585796b1
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panic.rs:142:14
  41:     0x56392db998fb - std::rt::lang_start_internal::{{closure}}::h494c7ce8e920f855
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:148:48
  42:     0x56392db998fb - std::panicking::try::do_call::h477263181d31b564
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:500:40
  43:     0x56392db998fb - std::panicking::try::h528ee19113a9c71d
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panicking.rs:464:19
  44:     0x56392db998fb - std::panic::catch_unwind::hf6ad906670aa97c3
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/panic.rs:142:14
  45:     0x56392db998fb - std::rt::lang_start_internal::h126bbcf1683f341d
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:148:20
  46:     0x56392c753c3a - std::rt::lang_start::h0c21882824dd6ef7
                               at /rustc/993deaa0bf8bab9dd3eadfd1fbeb093328e95afe/library/std/src/rt.rs:165:17
  47:     0x56392c77a42e - main
  48:     0x7fcf23a20d90 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  49:     0x7fcf23a20e40 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:392:3
  50:     0x56392c7534e5 - _start
  51:                0x0 - <unknown>

Changing the following line:

To:

let instance = wgpu::Instance::new(wgpu::InstanceDescriptor {
    backends: wgpu::Backends::PRIMARY,
    dx12_shader_compiler: Default::default(),
});

Fixes the issue. The issue only happens when using the GL backend.

I'm using Ubuntu 22.04 running in WSL2, on top of Windows 10 build 19045.

WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3086

I see that the crate is still not published in crates.io, and therefore it is also not part of https://areweguiyet.com/

Would you consider publishing it to keep track of your approach in the GUI in Rust landscape?

Two runs:

RUST_BACKTRACE=1 cargo run -- -w
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/lapce -w`
2023-08-30T21:44:38.360517Z ERROR lapce_app::keypress: Failed to load from "/home/luke/.config/lapce-debug/keymaps.toml": no keymaps
2023-08-30T21:44:39.957400Z ERROR wgpu_hal::gles::egl: EGL 'eglGetPlatformDisplay' code 0x3004: eglGetPlatformDisplay    
thread 'main' panicked at 'Error in Surface::configure: Validation Error

Caused by:
    Parent device is lost
', /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/backend/direct.rs:771:18
stack backtrace:
   0: rust_begin_unwind
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/panicking.rs:67:14
   2: wgpu::backend::direct::Context::handle_error_fatal
             at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/backend/direct.rs:345:9
   3: <wgpu::backend::direct::Context as wgpu::context::Context>::surface_configure
             at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/backend/direct.rs:771:13
   4: <T as wgpu::context::DynContext>::surface_configure
             at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/context.rs:2154:9
   5: wgpu::Surface::configure
             at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/lib.rs:4581:9
   6: floem_vger::VgerRenderer::new
             at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/vger/src/lib.rs:73:9
   7: floem::renderer::Renderer::new
             at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/renderer.rs:68:20
   8: floem::context::PaintState::new
             at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/context.rs:1161:23
   9: floem::window_handle::WindowHandle::new
             at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/window_handle.rs:73:27
  10: floem::app_handle::ApplicationHandle::new_window
             at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/app_handle.rs:196:29
  11: floem::app::Application::window
             at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/app.rs:98:9
  12: lapce_app::app::AppData::create_windows
             at ./lapce-app/src/app.rs:322:27
  13: lapce_app::app::launch
             at ./lapce-app/src/app.rs:3305:15
  14: lapce::main
             at ./lapce-app/src/bin/lapce.rs:4:5
  15: core::ops::function::FnOnce::call_once
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

WGPU_BACKEND=gl WGPU_ADAPTER_NAME="UHD" RUST_BACKTRACE=full cargo run -- -w
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/lapce -w`
2023-08-30T21:38:16.715649Z ERROR lapce_app::keypress: Failed to load from "/home/luke/.config/lapce-debug/keymaps.toml": no keymaps
2023-08-30T21:38:16.902593Z ERROR wgpu_hal::gles::egl: EGL 'eglGetPlatformDisplay' code 0x3004: eglGetPlatformDisplay    
thread 'main' panicked at 'Error in Surface::configure: Validation Error

Caused by:
    Parent device is lost
', /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/backend/direct.rs:771:18
stack backtrace:
   0:     0x55bf91c12f61 - std::backtrace_rs::backtrace::libunwind::trace::he648b5c8dd376705
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55bf91c12f61 - std::backtrace_rs::backtrace::trace_unsynchronized::h5da3e203eef39e9f
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55bf91c12f61 - std::sys_common::backtrace::_print_fmt::h8d28d3f20588ae4c
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:65:5
   3:     0x55bf91c12f61 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd9a5b0c9c6b058c0
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x55bf91c47e1f - core::fmt::rt::Argument::fmt::h0afc04119f252b53
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/fmt/rt.rs:138:9
   5:     0x55bf91c47e1f - core::fmt::write::h50b1b3e73851a6fe
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/fmt/mod.rs:1094:21
   6:     0x55bf91c0bc07 - std::io::Write::write_fmt::h184eaf275e4484f0
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/io/mod.rs:1714:15
   7:     0x55bf91c12d75 - std::sys_common::backtrace::_print::hf58c3a5a25090e71
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x55bf91c12d75 - std::sys_common::backtrace::print::hb9cf0a7c7f077819
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x55bf91c14453 - std::panicking::default_hook::{{closure}}::h066adb2e3f3e2c07
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:269:22
  10:     0x55bf91c141e4 - std::panicking::default_hook::h277fa2776900ff14
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:288:9
  11:     0x55bf91c14a49 - std::panicking::rust_panic_with_hook::hceaf38da6d9db792
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:705:13
  12:     0x55bf91c14947 - std::panicking::begin_panic_handler::{{closure}}::h2bce3ed2516af7df
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:597:13
  13:     0x55bf91c133c6 - std::sys_common::backtrace::__rust_end_short_backtrace::h090f3faf8f98a395
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:151:18
  14:     0x55bf91c14692 - rust_begin_unwind
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:593:5
  15:     0x55bf91c44933 - core::panicking::panic_fmt::h4ec8274704d163a3
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/panicking.rs:67:14
  16:     0x55bf907e39e4 - wgpu::backend::direct::Context::handle_error_fatal::hbb2f275bb544ea81
                               at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/backend/direct.rs:345:9
  17:     0x55bf907eae08 - <wgpu::backend::direct::Context as wgpu::context::Context>::surface_configure::h7d5b1336817cf0d1
                               at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/backend/direct.rs:771:13
  18:     0x55bf90804684 - <T as wgpu::context::DynContext>::surface_configure::h62637b451c335751
                               at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/context.rs:2154:9
  19:     0x55bf90887520 - wgpu::Surface::configure::h0522ee74ef29c608
                               at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.0/src/lib.rs:4581:9
  20:     0x55bf901d6b97 - floem_vger::VgerRenderer::new::h0b6622016ebbf1e2
                               at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/vger/src/lib.rs:73:9
  21:     0x55bf901c5256 - floem::renderer::Renderer::new::h36023c4c932fc661
                               at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/renderer.rs:68:20
  22:     0x55bf901027fe - floem::context::PaintState::new::h63d7128386c2a93f
                               at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/context.rs:1161:23
  23:     0x55bf9011278c - floem::window_handle::WindowHandle::new::h389dac1df0c7b66a
                               at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/window_handle.rs:73:27
  24:     0x55bf90140c3e - floem::app_handle::ApplicationHandle::new_window::h1d313a716654d574
                               at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/app_handle.rs:196:29
  25:     0x55bf8c8d5a4a - floem::app::Application::window::hada86382721c17a6
                               at /home/luke/.cargo/git/checkouts/floem-69eea0a757d1e3ee/53823652d957/src/app.rs:98:9
  26:     0x55bf8c430fa2 - lapce_app::app::AppData::create_windows::h0cd7d481c55c1155
                               at /home/luke/Projects/lapce/lapce-app/src/app.rs:322:27
  27:     0x55bf8c43a16e - lapce_app::app::launch::ha92c911aa3b7a84e
                               at /home/luke/Projects/lapce/lapce-app/src/app.rs:3305:15
  28:     0x55bf8bb33207 - lapce::main::h5fb7151bb68e6583
                               at /home/luke/Projects/lapce/lapce-app/src/bin/lapce.rs:4:5
  29:     0x55bf8bb331ab - core::ops::function::FnOnce::call_once::h3c64005149980313
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:250:5
  30:     0x55bf8bb3323e - std::sys_common::backtrace::__rust_begin_short_backtrace::h958691ec0c13a7aa
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:135:18
  31:     0x55bf8bb33161 - std::rt::lang_start::{{closure}}::h37f5d85c751e40cd
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/rt.rs:166:18
  32:     0x55bf91c04a2b - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h75ba4244a1c7bb54
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:284:13
  33:     0x55bf91c04a2b - std::panicking::try::do_call::h0a2baa36dea975a1
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:500:40
  34:     0x55bf91c04a2b - std::panicking::try::h0e42aa233d4224d4
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:464:19
  35:     0x55bf91c04a2b - std::panic::catch_unwind::hefdfd8f482606434
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panic.rs:142:14
  36:     0x55bf91c04a2b - std::rt::lang_start_internal::{{closure}}::h457959f0f91da23b
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/rt.rs:148:48
  37:     0x55bf91c04a2b - std::panicking::try::do_call::h112cfd1acb38183b
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:500:40
  38:     0x55bf91c04a2b - std::panicking::try::ha64f15b20cec18ca
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:464:19
  39:     0x55bf91c04a2b - std::panic::catch_unwind::hbacc2b68ee2c119e
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panic.rs:142:14
  40:     0x55bf91c04a2b - std::rt::lang_start_internal::h5f408694586c2a05
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/rt.rs:148:20
  41:     0x55bf8bb3313a - std::rt::lang_start::hb8450eefc57d1f6f
                               at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/rt.rs:165:17
  42:     0x55bf8bb3322e - main
  43:     0x7f700d62814a - __libc_start_call_main
  44:     0x7f700d62820b - __libc_start_main_alias_2
  45:     0x55bf8bb33025 - _start
  46:                0x0 - <unknown>

Graphics: Intel UHD Graphics 770 + RTX4080
Distro: Fedora 39

Possible related issues:

• rerun-io/rerun#1250
• gfx-rs/wgpu#3043
• gfx-rs/wgpu#2519

     Running `/home/luke/Projects/floem/target/debug/counter`
warning: queue 0x559c196f8870 destroyed while proxies still attached:
  wl_registry@2 still attached
thread 'main' panicked at 'Error in Surface::configure: invalid surface', /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.15.1/src/backend/direct.rs:316:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: queue 0x559c196fa3f0 destroyed while proxies still attached:
  wl_display@1 still attached

…/examples/counter on  main is 📦 v0.1.0 via 🦀 v1.69.0 
❯ __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.11s
     Running `/home/luke/Projects/floem/target/debug/counter`
warning: queue 0x55c4fb38de40 destroyed while proxies still attached:
  wl_registry@2 still attached
warning: queue 0x55c4fb38fe00 destroyed while proxies still attached:
  zwp_linux_dmabuf_v1@6 still attached

Per output above, the first block is Intel GPU. Second is offload to Nvidia. When offloaded to Nvidia the example runs fine (and so does lapce floem branch).

I've not much experience with wgpu, but usually when I've encountered this it's been to do with pixel colour types or maybe blending.

Border Radius applied to a stack

Border radius applied to clip

I haven't found the root of the problem but I think it is related to a list being inside of a scroll inside of a container of some form at that doesn't have a specified size when the list has a corresponding size set to 100%.

This works

use floem::{style::Style, view::View, views::*, AppContext};

fn main() {
    floem::launch(app2);
}

fn app2(_cx: AppContext) -> impl View {
    container(|| {
        scroll(|| {
            list(
                move || (1..30).collect::<im::Vector<i32>>(),
                move |item| *item,
                move |item| {
                    container(|| label(move || format!("{item}")))
                        .style(|| Style::BASE.width_pct(100.))
                },
            )
            .style(move || Style::BASE.width_pct(100.))
        })
        .style(move || Style::BASE.border(2.).max_height_px(200.))
    })
    .style(|| Style::BASE.flex_col().width_pct(100.))
}

So I'm not sure where the issue is but this seems to be a cursed combo. Removing any of the styles in here seems to break everything.

Something weird. If you remove the style on the outer container the window never appears. But if you remove the border width then it works regardless of whether the outer style on the container is present.

It looks like there is an issue with the winit implementation since the menu code is commented out in the code base right now.
Possibly related to #17?
I figured I add an issue to track this.

We should have support for:

Application::new()
		.window(
			|_| {
				app_view().window_title(|| String::from("Vault")).window_menu(|| {
					Menu::new("")
						.entry(MenuItem::new("Menu item"))
						.entry(MenuItem::new("Menu item with something on the\tright"))
				})
			},
			Some(WindowConfig::default().size(Size::new(800.0, 350.0)).title("Vault")),
		)
		.run();

Which would result in a global menu much like this one in macos:

I don't know what is this

Floem views will only restrict the viewport of its child if it has an explicit height set. If the height of the view is computed using flex-grow then the view will just grow to the size of the child element and overflow its own parent.

When debugging the scroll view specifically I can see that the proper height is calculated in actual-rect initially but on a following compute_layout it is then changed to the size of the child view. I can't find where this is happening.

child-size: 0.0W×0.0H
new-child-size: 292.5W×217.5H
actual-rect: Rect { x0: 0.0, y0: 0.0, x1: 0.0, y1: 0.0 }

child-size: 292.5W×217.5H
new-child-size: 292.5W×217.5H
actual-rect: Rect { x0: 0.0, y0: 0.0, x1: 390.0, y1: 142.52499389648438 }        <<-- Should be this size

child-size: 292.5W×217.5H
new-child-size: 292.5W×217.5H
actual-rect: Rect { x0: 0.0, y0: 0.0, x1: 390.0, y1: 217.5 }                     <<-- Is changed here

child-size: 292.5W×217.5H
new-child-size: 292.5W×217.5H
actual-rect: Rect { x0: 0.0, y0: 0.0, x1: 390.0, y1: 217.5 }

The above is produced using this code in scroll.rs

    fn update_size(&mut self, app_state: &mut AppState) {
        let child_size = self.child_size;
        let new_child_size = self.child_size(app_state).unwrap_or_default();
        self.child_size = new_child_size;

        self.actual_rect = app_state.get_content_rect(self.id);
        eprintln!(
            "child-size: {:?} \nnew-child-size: {:?} \nactual-rect: {:?}\n",
            child_size, new_child_size, self.actual_rect
        );

        // Round to prevent loops due to floating point accuracy
        if (child_size * 128.0).round() != (new_child_size * 128.0).round() {
            app_state.request_layout(self.id);
        }
    }

Minimized example.

fn settings_page() -> impl View {
      stack((
          text("Settings"),
          scroll(
              stack((
                  text("new thing"),
                  text("new thing"),
                  text("new thing"),
                  text("new thing"),
                  text("new thing"),
                  text("new thing"),
              ))
              .style(|s| {
                  s.gap(PxPct::Px(0.), PxPct::Px((6. * 2.) as f64))
                      .width(75.pct())
                      .flex_col()
              }),
          )
          .style(|s| s.width_full().flex_grow(1.).justify_center()), // <- If I set an explicit height here then the scroll works properly. 
      ))
      .style(|s| {
          s.set(GRAY)
              .size(70.pct(), 30.pct())
              .items_center()
              .gap(PxPct::Px(0.), PxPct::Px((6. * 2.) as f64))
              .padding(6.)
              .flex_col()
      })
      .on_click(|_| true),
   
}

It would be good to give VirtualListVector a lifetime for the iterator.
Ex:
If we wanted to implement VirtualListVector for [T; N] where T: Clone, it might be desirable to have the iterator not clone the entire array at once in case it is large. So we'd have ItemIterator be std::iter::Copied<std::slice::Iter<'_, T>>.. but we can't specify any lifetime other than static which just won't work.
Ex:
If we wanted to implement VirtualListVector for Vec<T> where T: Clone then we could avoid a whole new heap allocation via letting the iterator hold a reference to it
Similarly, even im::Vector is having to clone the sliced part to an entire new vector when it is used.

I haven't taken a close look at whether this would cause any problems.
It might also be more desirable to return a &T instead? So a borrowed iterator.

Not really sure how to debug the issue but I'm getting a panic on using signal.update(...) after using signal.get_untracked(). The panic is unwrapping a None. panic here

You can see that is_hovered correctly goes from false to true but the resulting behavior is strange.

It only plays the animation when it goes back to false from being true:

It would also be interesting to know how to not initially play the animation on start up.

I like the syntax and solid-like approach to Floem. My favourite syntax that I've seen so far; clean and elegant... although .animation(animation()) looks a little odd and confusing to me

The position cursor isn't showing (nothing blinking) in a text field even though the field has received focus:

Once I start typing (at least one) the first letter the cursor shows up (blinking as it should):

Deleting the last character out of the field brings us back to no cursor...

When running the counter example you can use the tab key to move between the two active elements. When you get to the end the focus is returned to the beginning. However the app crashes when you use shift + tab to go backwards.

On macos anyway.

Backtrace below:

thread 'main' panicked at src/view.rs:574:67:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: rust_begin_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
   1: core::panicking::panic_fmt
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:127:5
   3: core::option::Option<T>::unwrap
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/option.rs:935:21
   4: floem::view::view_tree_previous::{{closure}}
             at /Users/dominik/Sites/floem/src/view.rs:574:55
   5: core::option::Option<T>::or_else
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/option.rs:1514:21
   6: floem::view::view_tree_previous
             at /Users/dominik/Sites/floem/src/view.rs:572:5
   7: floem::view::view_tab_navigation::{{closure}}
             at /Users/dominik/Sites/floem/src/view.rs:490:13
   8: floem::view::view_tab_navigation
             at /Users/dominik/Sites/floem/src/view.rs:499:21
   9: floem::window_handle::WindowHandle::event
             at /Users/dominik/Sites/floem/src/window_handle.rs:214:29
  10: floem::window_handle::WindowHandle::key_event
             at /Users/dominik/Sites/floem/src/window_handle.rs:384:13
  11: floem::app_handle::ApplicationHandle::handle_window_event
             at /Users/dominik/Sites/floem/src/app_handle.rs:177:17
  12: floem::app::Application::run::{{closure}}
             at /Users/dominik/Sites/floem/src/app.rs:135:21
  13: <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event::{{closure}}
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:87:13
  14: winit::platform_impl::platform::app_state::EventLoopHandler<T>::with_callback
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:70:13
  15: <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:86:9
  16: winit::platform_impl::platform::app_state::Handler::handle_nonuser_event
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:314:13
  17: winit::platform_impl::platform::app_state::AppState::cleared
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:616:21
  18: winit::platform_impl::platform::observer::control_flow_end_handler::{{closure}}
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/observer.rs:79:21
  19: winit::platform_impl::platform::observer::control_flow_handler::{{closure}}
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/observer.rs:41:9
  20: std::panicking::try::do_call
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:504:40
  21: ___rust_try
  22: std::panicking::try
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:468:19
  23: std::panic::catch_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panic.rs:142:14
  24: winit::platform_impl::platform::event_loop::stop_app_on_panic
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:465:11
  25: winit::platform_impl::platform::observer::control_flow_handler
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/observer.rs:39:5
  26: winit::platform_impl::platform::observer::control_flow_end_handler
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/observer.rs:74:9
  27: <unknown>
  28: <unknown>
  29: <unknown>
  30: <unknown>
  31: <unknown>
  32: <unknown>
  33: <unknown>
  34: <unknown>
  35: <unknown>
  36: <unknown>
  37: <() as objc2::message::MessageArguments>::__invoke
             at /Users/dominik/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/message/mod.rs:531:39
  38: objc2::message::platform::send_unverified
             at /Users/dominik/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/message/apple/mod.rs:35:34
  39: objc2::message::MessageReceiver::send_message
             at /Users/dominik/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/message/mod.rs:233:53
  40: winit::platform_impl::platform::appkit::application::NSApplication::run
             at /Users/dominik/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/macros/__attribute_helpers.rs:126:21
  41: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}::{{closure}}
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:306:26
  42: core::ops::function::FnOnce::call_once
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/ops/function.rs:250:5
  43: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panic/unwind_safe.rs:271:9
  44: std::panicking::try::do_call
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:504:40
  45: ___rust_try
  46: std::panicking::try
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:468:19
  47: std::panic::catch_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panic.rs:142:14
  48: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:295:32
  49: objc2::rc::autorelease::autoreleasepool
             at /Users/dominik/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/rc/autorelease.rs:438:15
  50: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:277:9
  51: winit::platform_impl::platform::event_loop::EventLoop<T>::run
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:244:9
  52: winit::event_loop::EventLoop<T>::run
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/event_loop.rs:249:9
  53: floem::app::Application::run
             at /Users/dominik/Sites/floem/src/app.rs:128:17
  54: floem::app::launch
             at /Users/dominik/Sites/floem/src/app.rs:27:5
  55: counter::main
             at ./src/main.rs:87:5
  56: core::ops::function::FnOnce::call_once
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:377:33:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }
stack backtrace:
   0: rust_begin_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
   1: core::panicking::panic_fmt
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/result.rs:1652:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/result.rs:1077:23
   4: winit::platform_impl::platform::app_state::AppState::clear_callback
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/app_state.rs:377:9
   5: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:325:13
   6: objc2::rc::autorelease::autoreleasepool
             at /Users/dominik/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/rc/autorelease.rs:438:15
   7: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:277:9
   8: winit::platform_impl::platform::event_loop::EventLoop<T>::run
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/platform_impl/macos/event_loop.rs:244:9
   9: winit::event_loop::EventLoop<T>::run
             at /Users/dominik/.cargo/git/checkouts/winit-1ee925e9c8358846/7608048/src/event_loop.rs:249:9
  10: floem::app::Application::run
             at /Users/dominik/Sites/floem/src/app.rs:128:17
  11: floem::app::launch
             at /Users/dominik/Sites/floem/src/app.rs:27:5
  12: counter::main
             at ./src/main.rs:87:5
  13: core::ops::function::FnOnce::call_once
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Implementation suggestions:
The API should look something like this:

fn app_view(cx: AppContext) -> impl View {
    let (is_checked, set_is_checked) = create_signal(cx.scope, false);
    click(
        cx,
        |cx| {
            stack(cx, |cx| {
                (
                    check_box(cx, move || is_checked.get()),
                    label(cx, || "Is checked?".to_string()),
                )
            })
        },
        move || set_is_checked.update(|checked| *checked = !*checked),
    )
}

The disabled fn in decorator.rs can be used as a reference to implement the checked fn of check_box.
The check_box should simply render a container with a border that has an svg for the check mark.

Bonus points if the checkbox is added to the widget-gallery example :)

The program crashes when you perform the example to resize a window.

log:
thread 'main' panicked at 'called Result::unwrap() on an Err value: Outdated', C:\Users\WL.cargo\git\checkouts\floem-69eea0a757d1e3ee\7bcd372\vger\src\lib.rs:346:56
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

• Click to edit at particular character
• Drag to select range
• Double click to select a word
• Ctrl + Arrow key to move by word
• Shift + Arrow keys to select
• Ctrl + backspace to delete word before the cursor
• Numpad del to delete the character after the cursor (Ctrl deletes the word)
• Ctrl + A to select all
• Cut, copy and paste shortcuts (need to access system clipboard)
• IME support
• Proper mouse cursor icon on hover and a blinking caret in the text box
• Optional multi line support (adding another component would be reasonable)
• Alignment and justification
• request_focus should put cursor at the end of the field
• Programmatically set selection / cursor location

See cursor rendering

I think computed style is a better name since most people will be familiar with it from web development.

Is this expected? I'm new to leptos. To reproduce, just cargo run on the widget gallery example.

At src/views/text_input.rs:326:14, you access a signal or memo (defined at examples/widget-gallery/src/inputs.rs:14:16) outside a reactive tracking context. This might mean your app is not responding to changes in signal values in the way you expect.

Here’s how to fix it:

1. If this is inside a `view!` macro, make sure you are passing a function, not a value.
  ❌ NO  <p>{x.get() * 2}</p>
  ✅ YES <p>{move || x.get() * 2}</p>

2. If it’s in the body of a component, try wrapping this access in a closure:
  ❌ NO  let y = x.get() * 2
  ✅ YES let y = move || x.get() * 2.

3. If you’re *trying* to access the value without tracking, use `.get_untracked()` or `.with_untracked()` instead.
At src/views/text_input.rs:326:14, you access a signal or memo (defined at examples/widget-gallery/src/inputs.rs:14:16) outside a reactive tracking context. This might mean your app is not responding to changes in signal values in the way you expect.

I can reproduce with this minimal code snippet:

struct Repro {
    id: Id,
    text: RwSignal<String>,
    child: TextInput,
}
fn repro() -> Repro {
    let cx = AppContext::get_current();
    let text = create_rw_signal(cx.scope, "Hello World!".to_string());
    let id = cx.new_id();
    let mut child_cx = cx;
    child_cx.id = id;
    AppContext::save();
    AppContext::set_current(child_cx);
    let child = text_input(text);
    AppContext::restore();
    Repro { id, child, text }
}

impl View for Repro {
    fn id(&self) -> Id {
        self.id
    }

    fn child(&mut self, id: Id) -> Option<&mut dyn View> {
        if self.child.id() == id {
            Some(&mut self.child)
        } else {
            None
        }
    }

    fn children(&mut self) -> Vec<&mut dyn View> {
        vec![&mut self.child]
    }

    fn debug_name(&self) -> std::borrow::Cow<'static, str> {
        "Repro".into()
    }

    fn update(&mut self, _cx: &mut UpdateCx, _state: Box<dyn std::any::Any>) -> ChangeFlags {
        ChangeFlags::empty()
    }

    fn layout(&mut self, cx: &mut LayoutCx) -> Node {
        cx.layout_node(self.id, true, |cx| vec![self.child.layout_main(cx)])
    }

    fn compute_layout(&mut self, cx: &mut LayoutCx) -> Option<Rect> {
        Some(self.child.compute_layout_main(cx))
    }

    fn event(&mut self, cx: &mut EventCx, id_path: Option<&[Id]>, event: Event) -> bool {
        self.child.event_main(cx, id_path, event)
    }

    fn paint(&mut self, cx: &mut PaintCx) {
        self.child.paint_main(cx);
    }
}

fn main() {
    floem::launch(repro);
}

Some programs need to load fonts dynamically because they're not installed on the system (ex: programs that package their fonts, or programs like pdf viewers that only have access at runtime).
It would be nice to allow this. I think it can be done with a newer version of cosmic-text, which exposes FontSystem as a parameter that can be passed around when constructing text.
I expect that we can capture most use-cases with a floem-wide FontSystem, but it would probably be easy to allow custom font systems as needed when constructing a TextLayout.
Though, newer versions of cosmic-text seem to get rid of TextLayout. However Buffer/BufferLine seem like they've become replacements, though I've only glanced at them.

When the input is set as a percentage and can be changed with the window size it may overflow the input itself as shown in the screenshot below.

Edit: When the placeholder is longer than the text_input it will always overflow regardless of what width the text_input is set to

Running this code results in a stack overflow. The code uses libloading to load a shared library libplugin.so

use floem::view::View;

fn main() {
    floem::launch(move || unsafe {
        let lib = libloading::Library::new("./target/debug/libplugin.so").unwrap();
        let func = lib
            .get::<unsafe fn() -> Box<dyn View>>(b"plugin_main")
            .unwrap();

        func()
    });
}

this the libplugin.so code

use floem::view::View;
use floem::views::{label, stack, text};

#[no_mangle]
pub fn plugin_main() -> Box<dyn View> {
    let view = stack((
        label(move || format!("Value: {}", 0)),
        stack((
            text("Increment"), 
            text("Decrement"),
        )),
    ));

    Box::new(view)
}

this is the cargo runoutput

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
fish: Job 1, 'cargo run' terminated by signal SIGABRT (Abort)

Having an on_click handler overrides a pointer_up event listener. This makes sense I guess because a click event does happen on pointer up but it isn't clear that setting an on_click handler and a handler on pointer_up should override each other. For consistency it might make sense to just have a the pointer_up event and remove the on_click handler

Commit e4adc18 breaks being able to focus a text input

I'm curious, what is this repository for? What does it do?

Using Mobaxterm and vcxsrv to as X server.
The window is black at all.

cargo run --package counter
Finished dev [unoptimized + debuginfo] target(s) in 0.54s
Running target/debug/counter
[/home/lion/.cargo/git/checkouts/glazier-3a172f69e2427c5a/58cd5a4/src/backend/x11/application.rs:673] ev = MapNotify(
MapNotifyEvent {
response_type: 19,
sequence: 200,
event: 2097154,
window: 2097154,
override_redirect: false,
},
)
[/home/lion/.cargo/git/checkouts/glazier-3a172f69e2427c5a/58cd5a4/src/backend/x11/application.rs:673] ev = ReparentNotify(
ReparentNotifyEvent {
response_type: 149,
sequence: 202,
event: 2097154,
window: 2097154,
parent: 197,
x: 34,
y: 415,
override_redirect: true,
},
)