EventLoop creation can fail on Linux.

[kayabaNerve]

EventLoop::new can, and will, fail on Linux when the display server isn't active. This is most easily reproduced via switching to a different TTY and trying to run a Tao app. While this does seem a bit out of scope (trying to run a GUI app on a system without a UI running), having a way to handle this would be optimal.

As of right now, window creation does return a result. On that same path, having event loop creation return a result seems feasible, yet would mean an API break. Alternatively, a new function to check if the GUI is accessible could work.

With GTK specifically, gtk_init_check exists and will return a GBoolean of false if the display server couldn't be connected to. That said, Tao uses the Application API instead of gtk_init. It is possible to run gtk_init multiple times though, so having one call to gtk_init_check before a call to the Application API could work.

Locally, while working with Wry, I was able to implement this via

use gtk;
fn new_webview() -> wry::Result<CustomWebViewDataType> {
  //Make sure WebView is available.
  webview::webview_version()?;
  match gtk::init() {
    Err(e) => Err(wry::Error::GlibBoolError(e)),
    Ok(_) => {
      let event_loop: EventLoop<()> = EventLoop::new();
      ...

That said, this is suboptimal for multiple reasons. My main comment is that Tao is in the perfect position to handle this. I had to look at the GTK version being used, specify it myself, and directly call it, when the expectation is on Tao to manage GTK (and other backends which may have similar quirks). There's also an expectation on EventLoop::new to never error, given it's lack of a Result return type, when it easily can error (my cited cases were VPSs, people who have Xorg yet don't always run it, and people who use TTYs instead of terminal emulators).

In conclusion, modifying EventLoop::new to return a Result, or adding another function to check if a GUI is accessible in a way that allows the app to handle the case where it's not, would be greatly appreciated. While work arounds exist, and this is a bit niche, Tao is in the perfect position to handle this and should as a multi platform window manager.

[nothingismagick]

Thanks @kayabaNerve - I am sort of wondering if this is similar to the problem that @chippers ran into yesterday with linux...

[chippers]

Not sure if this is appropriate for your usecase, but you can run a virtual display for your program. Try xvfb-run my_tao_app which should create a virtual memory display that is not actually drawn to a real screen. I use this method in CI to run headless WebDriver tests.

Thanks @kayabaNerve - I am sort of wondering if this is similar to the problem that @chippers ran into yesterday with linux...

Probably not, that had to do with webkit2gtk's WebContext and there was a display

[kayabaNerve]

Sorry, yet that's not the issue described at all.

I'm trying to deploy an app that won't panic if accidentally run on a server. This isn't about unit testing or controlled environments. It is possible not to panic, if the EventLoop returns a Result indicating it failed. As of right now, Tao panics for me. The reason I want this functionality merged into Tao, and not present in my app, is because:

1. It's technically accurate for the EventLoop to return a Result of itself.
2. I would literally have to rewrite Tao for this functionality to be otherwise available. I would need to call gtk myself, and handle its init code. Tao is in the position to do this natively, and would offer a solution expandable as alternative instances of this issue appear on macOS/Windows (if they do; I'm decently sure headless macOS is a thing).

Beyond a Result for EventLoop, an API change, a function to check if EventLoop instantiation is possible would be appreciated. I described in my initial post a GTK hack that would enable such behavior (double initialization which is fine, at least in my minimal test; one using one API which returns a bool and one via Tao which uses a different API yet makes the same call).

Thanks for the suggestion though.