Question on IOChannel

[lukasstevens]

I have a question: Is there a way to listen to stdin in the gtk main loop?
Are there any plans to port GIOChannel which is currently only available through glib_sys::GIOChannel?

[GuillaumeGomez]

Why would you want to read stdin in a GUI application?

[lukasstevens]

My use case is relatively specific. I want to create a status bar with the same interface as i3bar. Meaning that the output of the i3status command is piped to my application. The information is then read from the stdin and displayed accordingly. For displaying the information I use gtk-rs and webkit2gtk.

EDIT: I probably could put out the information with a local webserver and view it with the webview.

[gkoz]

Reading from stdin should be doable with just Rust's libstd why bother going through glib?

[lukasstevens]

Maybe I am under the wrong impression, but I thought you can only read input with rusts facilities by adding your function as a callback via idle_add. With an IOChannel you would be able to add it to the event loop and you would get a callback only when there is input to read.

[gkoz]

Oh right, with the blocking API in libstd you'd be forced to perform IO in a separate thread... That might not be a bad thing though. BTW I've been hacking on a way to wake up the event loop from other threads via a pipe like gtkmm's Dispatcher does. You wouldn't have to pay for idle_add overhead then.

[lukasstevens]

Yeah that is exactly what I am doing right now. I start a seperate thread for reading input which is then send over a channel. I then add a callback via idle_add in which I use try_recv to check if there is any new input.

[gkoz]

There's an issue that try_recv in a repetitive idle_add callback will still eat CPU unnecessarily. You'll get better results by either using timeout_add or scheduling a one-off recv with idle_add every time there's something to receive like this.

[lukasstevens]

Thanks for the heads-up. Is there a reason you don't add the callback outside of the thread::spawn? I just moved the receiver to the scope of the callback and then I just try_recv for every callback.

[gkoz]

A perpetual idle_add callback will get called continuously eating up any idle CPU. One way to avoid that is to schedule a handler when there's some data to receive and let it disconnect itself after receiving the data (Continue(false)).

[lukasstevens]

Ah I understand now. Seeing this I think it would be a nice quality of live improvement if there is something like GIOChannel or a similiar solution.

[lukasstevens]

I was just revisiting this and wanted to implement your solution since it is obviously better, but I encountered the problem that I can't use this method when I want to read input while the gtk main loop is running since gtk may only be accessed from the main thread. This means I can not call gtk::idle_add.

Edit: Scratch that I was using gtk::idle_add when I should have been using glib::idle_add.

[sdroege]

@GuillaumeGomez Close this, it's a duplicate of https://github.com/gtk-rs/glib/issues/186 :)