fltk-rs: [BUG] Application UI Freezes depending on which Monitor app is launched from

Describe the bug

Simple application with buttons seems to “lock up” when pressing buttons. That is the buttons appearance freezes. Either the button seems to not register the click at all, or it registers the down press but not the up press. The behavior seems to occur %40-%50 of the time the app is run, and sometimes the buttons work as expected. Not receiving any error messages, and the entire app process doesn’t seem to freeze (can still drag, resize, and minimize the window), but can no longer interact with the UI.

Thought it might have been something with my system so I gave my computer a restart but the issue still persists.

EDIT: Resizing the window seems to cause the button to unfreeze and respond as expected.

OS: Win 10

Expected behavior

Expect button to react normally to clicks.

The buttons in the below code are not laid out exactly the same as the one’s in the screenshots, but they produce the same behavior.

//fltk = { version = "^1.0.18"}
use fltk::{app, button::Button, group::*, enums::*, prelude::*, window::Window};
use std::thread;

fn main(){
    let app = app::App::default();
    let mut wind = Window::default().with_size(500, 200).with_label("Counter");
    wind.make_resizable(true);
    let dummy_button = Button::new(100,100,100,100, "dummy");
    let dummy_button = Button::new(200,100,100,100, "dummy");
    wind.end();
    wind.show();
    app.run().unwrap();
}

Buttons not reacting to any clicks: failure_1 Button stuck in “down” state: failure_2

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 46 (5 by maintainers)

Most upvoted comments

@MoAlyousef [dependencies] fltk = { version = "1.0.20", git = "https://github.com/fltk-rs/fltk-rs", features = ["no-gdiplus"] } fixed the issue. @eadf yes I have, when you press the buttons you can still get a console output, the buttons just dont draw correctly. I didn’t test this extensively though. CPU Load doesn’t spike/throttle/peak.

wyhinton on Jun 21, 2021

I’ve added a no-gdiplus in master, can you try it:

[dependencies]
fltk = { version = "1.0.20", git = "https://github.com/fltk-rs/fltk-rs", features = ["no-gdiplus"] }

MoAlyousef on Jun 21, 2021

^This. I had meant to write set(OPTION_USE_GDIPLUS ON CACHE BOOL " " FORCE). Apparently I was tired 😃 @wyhinton, can you try building the C++ repro with the modified option, can you also try with the latest fltk-rs.

Thanks @Albrecht-S

MoAlyousef on Jun 29, 2021

[Some comments from a FLTK developer (me).]

I’m not using Rust (and fltk-rs) myself yet but I’m interested in doing so. I’m late to the party, but I read this thread and noticed some points. Unfortunately I can’t test with a dual monitor setup right now – I may start a Win10 box with two equal monitors later though…

Note: FLTK 1.4.0 is still in development (pretty stable), and the GDI+ extension is certainly in some kind of beta state (but works pretty well as far as we can tell). There have not been many extensive tests though. The default FLTK 1.4 build enables GDI+ intentionally so we receive more test results. Maybe there are some yet unnoticed bugs? I take it that fltk-rs uses the default build (GDI+ enabled).

That said, the instructions in https://github.com/fltk-rs/fltk-rs/issues/740#issuecomment-865332904 for building the C++ version of the demo explicitly disable GDI+ in CMakeLists.txt with set(OPTION_USE_GDIPLUS OFF CACHE BOOL " " FORCE). So the only thing we know from testing with the C++ FLTK version is that it works if GDI+ is disabled (and the same if using the fltk-rs version). It would be interesting to see if the OP @wyhinton can reproduce the issue with the C++ version with set(OPTION_USE_GDIPLUS ON CACHE BOOL " " FORCE) instead.

Albrecht-S on Jun 29, 2021

@MoAlyousef Thanks for this confirmation. Good to know that there’s no issue in FLTK (now).

Albrecht-S on Jun 29, 2021

To resolve the link error, you can try adding gdiplus to the last line: target_link_libraries(main PRIVATE fltk gdiplus)

@wyhinton, it’s the screen_xywh(screen_num) which returns a tuple with (x, y, w, h)

But the initial issue seems to have been resolved with: https://github.com/fltk/fltk/commit/713d1bfd7c4a538b7bd3625a5f521f5911a9f500

MoAlyousef on Jun 29, 2021

You can clone the repo and try changing some stuff. For example the only difference between that Rust and C++ versions of the demo program:

The init codes in App::default(). You can try disabling that.
Window::default() calls free_position, you can try using Window::new().
The linking of fltk’s image libs at build time (fltk by default builds without image support). You can try using the no-images feature.
You can also try to reproduce using the windows-gnu toolchain.

The rest of the differences arise from differences between Rust and C++ binaries in general, since Rust does more on startup and exit than C++ (https://github.com/rust-lang/rust/blob/a9ca1ec9280ca1e5020edd699917c3367a30a798/src/libstd/rt.rs), also binaries built using llvm and linking with libs built with msvc. Unfortunately these are things I don’t have the bandwidth to explore in detail.

If you find anything you can report here.

MoAlyousef on Jun 22, 2021

It should be placed at the top of the file, before everything. As for versions, to specify a specific version it should be marked with an equals sign: fltk = "=1.0.14"

MoAlyousef on Jun 21, 2021