audulus / rui Goto Github PK

Having trouble updating to winit 0.28.1.

Hover over a UI element and see where it's defined in your source code. Try the backtrace crate.

Was pretty excited to see where this project was heading when it was announce last year! I haven't seen or heard if much progress is still happening? If development is still active it would be great to see a change log with periodic updates.

Should be able to redraw only when state changes.

Docs could use some love: https://docs.rs/rui/0.1.8/rui/

For example, currently, sliders are built through composition of other views:

The view returned by hslider is an opaque type, so we can't add methods to it.

How can methods be added to the result of hslider while still defining hslider mostly as a function (i.e. not having to define it entirely in terms of an implementation of View)?

I'm working on a port of Flow to rui.

One immediate issue is with layout: a node in a node graph doesn't expand to fit the available space.

How can rui support that sort of layout?

It seems that SwiftUI doesn't actually expand stacks like rui does. Here's a simple SwiftUI VStack:

Here's a rui vstack:

Currently rui would require a GPU for automated testing. If we could provide a text layout interface to layout (instead of vger) then we could do testing without a GPU (GitHub CI VMs don't have GPUs)

I tried running the gradient example from the readme in my Windows 10:

use rui::*;

fn main() {
    rui(canvas(|rect, vger| {
        vger.translate(rect.center() - LocalPoint::zero());

        let paint = vger.linear_gradient(
            [-100.0, -100.0],
            [100.0, 100.0],
            AZURE_HIGHLIGHT,
            RED_HIGHLIGHT,
            0.0,
        );

        let radius = 100.0;
        vger.fill_circle(LocalPoint::zero(), radius, paint);
    }));
}

And it looks like:

When it is supposed to look like ( image from the readme ):

excepted display a circle and rectangle but the display is confused

[w@ww rui]$ rustc --version
rustc 1.59.0 (9d1b2106e 2022-02-23)
[w@ww rui]$ screenfetch -n
 w@ww
 OS: Manjaro 21.2.4 Qonos
 Kernel: x86_64 Linux 5.10.102-1-MANJARO
 Uptime: 1d 1h 9m
 Packages: 1541
 Shell: bash 5.1.16
 Resolution: 1920x1080
 DE: KDE 5.91.0 / Plasma 5.24.2
 WM: KWin
 GTK Theme: Adwaita-dark [GTK2/3]
 Icon Theme: breeze-dark
 Disk: 247G / 489G (53%)
 CPU: AMD Ryzen 9 5900X 12-Core @ 24x 3.7GHz
 GPU: NVIDIA GeForce GT 1030
 RAM: 20197MiB / 64288MiB

all example of rui not working on Linux with Nvidia graphic card

I'm trying to add state to button for hovering:

/// Calls a function when the button is tapped.
pub fn button<A: 'static, F: Fn(&mut Context) -> A + 'static>(view: impl View, f: F) -> impl View {
    state(
        || false,
        move |hover, _| {
            view.padding(Auto)
                .background(
                    rectangle()
                        .corner_radius(BUTTON_CORNER_RADIUS)
                        .color(BUTTON_BACKGROUND_COLOR),
                )
                .tap(move |cx| f(cx))
                .hover(|_, inside| {
                    println!("inside button: {}", inside);
                })
                .role(Role::Button)
        },
    )
}

The error here is that padding (or any other modifier) wants to move out of view, which is captured by the closure passed to state.

I'm not quite sure how to deal with this. I've tried making Views Clone, but it seems to cause a big ripple.

Buttons could use some polish. This wouldn't be hard :)

Following Xilem, try to make a statically typed state tree. If successful, this will eliminate the use of dyn Any in Context.

I get an error when running the example:

RUST_BACKTRACE=1 cargo run --example counter

then

    Finished dev [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/examples/counter`
Using Mesa Intel(R) UHD Graphics 630 (CFL GT2) (Gl)
thread 'main' panicked at 'wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `vger encoder`
    In a set_pipeline command
      note: render pipeline = `<RenderPipeline-(0, 1, Gl)>`
    Render pipeline targets are incompatible with render pass
    Incompatible color attachment: the renderpass expected [Some(Rgba8UnormSrgb)] but was given [Some(Bgra8UnormSrgb)]

', /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/wgpu-0.13.1/src/backend/direct.rs:2391:5
stack backtrace:
   0: rust_begin_unwind
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14
   2: wgpu::backend::direct::default_error_handler
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/wgpu-0.13.1/src/backend/direct.rs:2391:5
   3: core::ops::function::Fn::call
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/ops/function.rs:77:5
   4: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/alloc/src/boxed.rs:1954:9
   5: wgpu::backend::direct::ErrorSinkRaw::handle_error
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/wgpu-0.13.1/src/backend/direct.rs:2377:17
   6: wgpu::backend::direct::Context::handle_error
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/wgpu-0.13.1/src/backend/direct.rs:261:9
   7: <wgpu::backend::direct::Context as wgpu::Context>::command_encoder_end_render_pass
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/wgpu-0.13.1/src/backend/direct.rs:2087:13
   8: <wgpu::RenderPass as core::ops::drop::Drop>::drop
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/wgpu-0.13.1/src/lib.rs:3143:13
   9: core::ptr::drop_in_place<wgpu::RenderPass>
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/ptr/mod.rs:487:1
  10: vger::Vger::encode
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/vger-0.2.4/src/lib.rs:293:9
  11: rui::context::Context::render
             at ./src/context.rs:280:9
  12: rui::event_loop::rui::{{closure}}
             at ./src/event_loop.rs:385:17
  13: winit::platform_impl::platform::sticky_exit_callback
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/winit-0.26.1/src/platform_impl/linux/mod.rs:753:5
  14: winit::platform_impl::platform::wayland::event_loop::EventLoop<T>::run_return
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/winit-0.26.1/src/platform_impl/linux/wayland/event_loop/mod.rs:394:21
  15: winit::platform_impl::platform::wayland::event_loop::EventLoop<T>::run
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/winit-0.26.1/src/platform_impl/linux/wayland/event_loop/mod.rs:209:9
  16: winit::platform_impl::platform::EventLoop<T>::run
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/winit-0.26.1/src/platform_impl/linux/mod.rs:669:56
  17: winit::event_loop::EventLoop<T>::run
             at /home/timpaikx/.cargo/registry/src/mirrors.bfsu.edu.cn-4c6e9dcaa6bd74e7/winit-0.26.1/src/event_loop.rs:154:9
  18: rui::event_loop::rui
             at ./src/event_loop.rs:289:5
  19: counter::main
             at ./examples/counter.rs:4:5
  20: core::ops::function::FnOnce::call_once
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fish: Job 1, 'RUST_BACKTRACE=1 cargo run --ex…' terminated by signal SIGSEGV (Address boundary error)

OS: Archlinux
DE: GNOME 43 Wayland
git commit: 15273d1

If you need more information, I'm more than happy to provide it

I'm not sure whether this is rui or vger-rs issue, but when I use vger path fill, the filled path "lingers", see attachment.

My code is roughly:

// start: LocalPoint, end: LocalPoint

canvas(|_cx, _rect, vger| {
    vger.move_to(start);
    vger.quad_to(end, end);
    vger.fill(red_paint);
})

Instead, use TLS for the context.

Hey guys I have some questions regarding this project:

1. Can this library be used to integrate into a game engine as easily as somehting like egui
2. Are there any caching capabilities even though it is immediate?
3. Does it compile for web as well?
4. Does it lock you into some kind of framework like iced does?

I m sorry, but I m curious,, are there plan to make android apk (native)?

(May also not work on macOS)

To reproduce:

1. cargo run --example gallery
2. Attempt to enter a symbol character in the text editor (such as !@#$%^&*)

Possibly related to #43.

@ruza-net

See https://eugenkiss.github.io/7guis/

I'd like to make some textboxes which are draggable. That means they'll be able to overlap, so I have to make the one that has been interacted with most recently float on top of the others.

Can I do it with the current facilities (without implementing this manually with canvas)?

Use https://github.com/rust-lang/mdBook

Some initial stuff is in https://github.com/audulus/rui/tree/main/docs

I was looking into using references instead of passing around a context, and it seems tricky. Just wanted to record somewhere how far I got.

This is close, but doesn't quite work:

    struct State<F, V> {
        f: F,
        state: String,
        phantom: std::marker::PhantomData<V>,
    }

    impl<'a, V: View + 'a, F: Fn(&'a String) -> V + 'a> View for State<F, V> {
        fn draw(&self) {
            (self.f)(&self.state).draw();
        }
    }

The problem is in F: Fn(&'a String) -> V + 'a. This says the entire closure cannot outlive the String passed in. That's not quite what we want. It's ok if the closure lives longer. What we want is for the return type (V) to live as long as the String passed in.

What we want is something like F: for<'a> Fn(&'a String) -> V<'a> where V is a higher-kinded-type, but rust doesn't (yet) have this feature.

https://doc.rust-lang.org/cargo/reference/features.html

In the "none" case, the user would supply their own rendering surface and events (e.g. when embedding an iOS app)

• selection
• fix insertion point position
• fix up/down arrow position
• long text is rendered outside of the view

Seems like an issue with vger-rs.

To the best of my understanding the expected behaviour for drag is that when a drag begins the callback should be called with GestureState::Began
This does not happen currently.
Here's a minimal example:

use rui::*;

fn main() {
    rui(rectangle()
        .corner_radius(5.0)
        .color(AZURE_HIGHLIGHT.alpha(0.8))
        // Trivial drag implementation that only prints GestureState.
        .drag(move |_cx, _delta, state, _| match state {
            GestureState::Began => {
                println!("Began");
            }
            GestureState::Changed => {
                println!("Changed");
            }
            GestureState::Ended => {
                println!("Ended")
            }
        })
        .padding(Auto)
    );
}

The output looks as follows:

$ cargo run
...
Using Intel HD Graphics 4000 (Metal)
Changed
Changed
Changed
Changed
Changed
Changed
Changed
Changed
Ended

This was unexpected to me. Maybe that's intended, but I just thought I'd let you know.

Use full paths instead of hashing the id paths. This makes debugging easier, and avoids potential collisions.

May want to use code generation. https://doc.rust-lang.org/cargo/reference/build-script-examples.html

In particular, the layout modifiers are different, as in SwiftUI.

It’s nice to see a UI toolkit inspired by SwiftUI, there’s a lot of things I really like about it, but I believe SwiftUI is just a VDOM-like frontend to UIKit/AppKit.

Anyway with regards to this library, wouldn’t it make more sense to build upon UIKit/AppKit APIs for iOS and macOS targets?

It’s all written in objective-c and therefore it’s viable to use from rust, and seems like you’d get much more mileage/utility from it.

A menu bar isn't rendered on Windows.

See tauri-apps/tao#343

According to here: tauri-apps/tao#343

This breaks rendering on linux.

I've tried changing this on my local fork, and the tests pass. Is this, however, a deliberate design decision?

Currently the bounding box for text is based on the geometry of the text, so "aaa" has a different bounding box than "AAA". This may require some digging down into vger.