Events loop backend

[tomaka]

Based on #267
cc @alexheretic

This PR ties the EventsLoop to a specific X11 or Wayland connection on Linux. Creating the EventsLoop also creates the connection. We still use a lazy_static for the X11 connection though, because of the badly-designed XSetErrorHandler function.

Also adds an EventsLoopExt trait in os::linux that allows choosing whether the EventsLoop uses X11 or Wayland. The default new() function has the same behaviour as today.

Breaking changes:

• Removes os::linux::get_x_connection(). I don't remember what it was used for, but it was a bad design anyway. We can always reintroduce an equivalent through the EventsLoopExt trait if required.
• get_available_monitors() and get_primary_monitor() are now methods of EventsLoop instead of being stand-alone.

[Ralith]

Always great to see a reduction in global state! For future work, I think we could get rid of the global X11 connection by handling errors through a lazy_static RwLock<Hashmap<*const Display, EventsLoopProxy>> or similar; it's not hot path, after all. Does that sound palatable?

[alexheretic]

Looks good! Great to remove the background backend initialisation, much more natural to access get_available_monitors() through some handle that clearly indicates the backend has been initialised.

In fact the EventsLoop is really a winit context, at least it fits that better in my understanding. I'm not sure how well people would take to changing the name though?

The documentation:

/// Usage will result in display backend initialisation ...

Now only really applies to EventsLoop::new(), so we can remove this from EventsLoop::get_available_monitors & EventsLoop::get_primary_monitor (which is also a sign that this change is good!)

[tomaka]

By the way, should the WINIT_UNIX_BACKEND environment variable be removed? I'd say yes.

[elinorbgr]

This looks good to me 👍

By the way, should the WINIT_UNIX_BACKEND environment variable be removed? I'd say yes.

I'd vote to keep it. It can be quite useful for debugging purposes, many other window-providing libraries provide a similar env variable, and mostly, as long as the wayland backend of winit is not completely functional (decorations are still lacking buttons for example, and a few other things), I think it's good to allow end-users of winit-based applications to opt-out of wayland.

[alexheretic]

By the way, should the WINIT_UNIX_BACKEND environment variable be removed? I'd say yes.

From my point of view I need XWayland functionality from winit. With this PR I have the ability to do that explicitly, so the env var is no longer strictly necessary for my use case.

As vberger mentions env vars have their advantages. For higher level consumers of winit it could allow this backend configuration. For my use case, where I directly construct the EventsLoop myself it allows me to avoid platform specific calls in my code.

But I can deal with either approach, so do whatever you think is best now. We can always reintroduce, or remove, the env var later.

[tomaka]

I really want to remove this environment variable in the long term, but I'm fine with keeping it for now if it's deemed necessary.

[tomaka]

Does someone want to review this? If not, I'll just merge myself in a day or two.

[Ralith]

The X11 and API parts look good to me.