enter_keys on macOS behaves in an odd manner

[crrodger]

Great work on relm, makes Gtk a pleasure to use with Rust.

I am raising this mostly for awareness and to see if anyone else is experiencing something similar. It is not holding up anything important.

I am working on a Rust/Gtk/Relm application on macOS and wanted to bolster the tests. Doing this so I can put on Github and will then send you a PR to include it if interesting.

I have been using code something like the following (this is a subset, hopefully enough to illustrate the problem). For reference the test code is located in the same file as the code that loads the screen layout from a .glade file.

impl Widget for Win {
   ...
   ...
   fn view(relm: &Relm<Self>, mut model: Self::Model) -> Self {
   ...
   ...
        let glade_src_main = include_str!("main_gui.glade");
        let builder_main = Builder::from_string(glade_src_main);
   ...
    Win {
       model,
       widgets,
       config,
    }
  }
   ...
}

#[test]
    fn enter_times() {
        let (component, widgets) = relm::init_test::<Win>(()).expect("init_test failed");
        let tz_selector_main = component.widget();
        let children = tz_selector_main.get_children();

        let time_entry = children.get(1).unwrap().clone().downcast::<Entry>().expect("Could not get time entry");
        
        enter_keys(&time_entry, "1");
        assert_text!(time_entry, "1");
        enter_keys(&time_entry, "2");
        assert_text!(time_entry, "12");
    }

Environment

macOS 11.1 - Big Sur
VSCode 1.52.1
relm 0.20.0
relm-test 0.20.0
gtk 0.9.0
gtk-test 0.6
rustc 1.50.0-nightly (same behaviour with stable 1.48)

What happens

I have noticed that on MacOS the first key entry '1' is sent to the Entry widget and then it appears as if code execution stops. If I press a key while in the Entry widget the next 'enter_keys' statement is executed and the key I have pressed are both sent to the Entry widget. I have seen the same behaviour in the key-events.rs example in the relm-examples package. I then performed the test on a Linux (Ubuntu 20.04) machine and it behaved as I would expect, all the keys were sent and each assert statement was executed as expected.

What was expected

The enter_keys function sends keys and continues.
As noticed by running the same test in the same app on an Ubuntu machine, the enter_keys function successfully sends the key and continues to the next statements and the test succeeds so it looks like it may be only applicable to macOS. I have not tested on Windows.

[crrodger]

Looking into this a bit deeper I am wondering if this is not an enigo issue rather than a relm one!?

[antoyo]

It might also be a race condition with the way relm-test waits for the event to happen.
Can you try with the master branch?
Have you tried using enter_key() instead?

[crrodger]

enter_key() funny enough does work. I did try it but ran into a problem with the ":" character, it keeps being sent as a ";" and that was when I tried enter_keys. I need the ":" character as it forms part of a time entry "hh:mm"

This made me think about trying something else. For the colon ":" I have now landed up using a sequence of

        key_press(&time_entry, key::Shift_L);
        key_press(&time_entry, key::colon);
        key_release(&time_entry, key::Shift_L);

which seems to work, certainly enough to work around the problem.

Thanks for responding.

[antoyo]

I published relm 0.21 which should fix the race condition I was talking about.
Could you try again with this version?

Also, if you want to contribute to this project, you could try adding OS X to the platforms tested on GitHub CI ;) .

[crrodger]

Thank you, have updated and will test it when I get a chance this week.

In principle I am keen to contribute but not sure my Rust is strong enough :-p but I will have a look at the Github CI stuff and see if I can contribute there...

[crrodger]

I did a quick check on the weekend and I am still getting that weird keys not being sent issue. I am going to dig into it a little bit deeper this week when I get some time and see if I can locate where it is going weird. Will see what I can find.