michaelfairley / rust-imgui-sdl2 Goto Github PK

Hello!
I have downloaded you repo and tried the example demo app.
It shows empty window, but looking at the code there is
ui.show_demo_window(&mut true);
So I assume there should be visible default demo imgui window

But it is not. What should it display actually?

Already implemented (and commented out), but needs imgui-rs 0.19 to be released to expose the functionality needed.

rust-imgui-sdl2 always declares a fixed minor version dependency in Cargo.toml for both imgui and sdl2. For instance, right now on master it is 0.7 and 0.34. This has always created many problems to me, because I need to coordinate updates of imgui and sdl2 exactly the way rust-imgui-sdl2 demands.

For instance, sometimes I would like to upgrade (or even downgrade) sdl2, and I can't do that because rust-imgui-sdl2 is demanding a fixed version. Basically, my application is forced by rust-imgui-sdl2 to use specific versions of those libraries, and the only knob I'm left with is the version of rust-imgui-sdl2 I can declared that I want. This is very limiting: those libraries are much larger than rust-imgui-sdl2, there are more developments going on, and it looks wrong that I can't benefit from those until rust-imgui-sdl2 declares that it's time to do it -- and when it does, maybe it updates both packages creating a different problem to me.

I think rust-imgui-sdl2 would better serve the community if it was less demanding on the precise versions. In theory, it should allow for maximum compatibility and declare the minimum version of either crate it compiles with, but leaving applications free to handle their own updates. For instance, it could use sdl2 = ^0.30 and imgui = ^0.4, or whatever are the minimum requirements. That would simplify my life a lot.

Thanks!

Now that SDL2 support has been added to the imgui upstream what is the status of this crate?

Should this crate be considered deprecated or does it still offer features that the upstream doesn't?

Hey excellent library!
As the title says, do you have any idea on how could this be implemented?

https://github.com/michaelfairley/rust-imgui-sdl2/blob/ffca07d9721f64b5082e4fd4dd42382a9ba30750/Cargo.toml#L14C1-L14C23

Because of this it is impossible to use the sdl2 crate with the recent changes which I need. Note that 0.36 has never been published (yet), and 0.35 is very old (two years), so it makes sense to remove this limitation, since many people want to actually use both, sdl2 crate and this one.

Hi !
I have an issue when I want to use the canvas with imgui.
Windows are completely white or blinking. I have reuse your demo to try.
This is the code I have tried :

...
let mut canvas = window.into_canvas().build().unwrap();
'running: loop {
        use sdl2::event::Event;
        use sdl2::keyboard::Keycode;

        for event in event_pump.poll_iter() {
            imgui_sdl2.handle_event(&mut imgui, &event);
            if imgui_sdl2.ignore_event(&event) { continue; }

            match event {
                Event::Quit {..} | Event::KeyDown { keycode: Some(Keycode::Escape), .. } => {
                    break 'running
                },
                _ => {}
            }
        }

        let ui = imgui_sdl2.frame(&canvas.window(), &mut imgui, &event_pump);

        ui.show_test_window(&mut true);

        unsafe {
            gl::ClearColor(0.2, 0.2, 0.2, 1.0);
            gl::Clear(gl::COLOR_BUFFER_BIT);
        }

        renderer.render(ui);

        canvas.window.gl_swap_window();

        canvas.present();

        ::std::thread::sleep(::std::time::Duration::new(0, 1_000_000_000u32 / 60));
    }

Thanks for your help,
Catvert.

Currently 0.33, when 0.34 exists.

The crate depends on imgui-rs version 0.5.0 while recently 0.6.0 (a month ago) has been released.
Please bump the version on this crate and the rust-imgui-opengl-renderer crate too.

It seems that passing the event_pump isn't very thread safe, I managed to get everything working great by mapping the sdl2 events to a HashMap structure and pushing it as resource state and modifying the handle_event and frame signatures.

It would be nice be a bit more data driven for the input states over passing a ref to the pump.
Possibly another function that accepts a struct, and another that accepts a pump.

I may be wrong, but I couldn't find a solution otherwise.