Get enum WaylandProtocolEvent in the event loop about wayland-rs HOT 9 CLOSED

The enum Event is here for future-proofing.

In mid term future, I plan to integrate protocols extensions such a xdg_shell (which is destined to replace the current wl_shell interface). And it will sit alongside the wayland protocol, so the Event enum will look like:

pub enum Event {
    Wayland(WaylandProtocolEvent),
    XdgShell(SdgShellProtocolEvent),
}

And then other protocols will probably be added.

For now, you can quickly unwrap one level of this enum using code such as

let Event::Wayland(evt) = evt;

to rebind the evt variable to the contents of the enum. Note however that such code will break as soon as a second protocol is added.

from wayland-rs.

Maybe better on a callback? And in addition to hdg_shell has been written can be protocol extensions, and to add support in the bindings will not be possible without source code changes of bindings.

from wayland-rs.

I've explicitly moved away from callbacks (which is the default behaviour of wayland) to iterators because the latter behave much more smoothly with Rust's type system than the former, so I don't plan to come back to callbacks.

Also, protocol extensions explicitly interact pretty tightly with the core protocol, so having them in other crates will hardly be possible without making the whole thing pretty unsafe and error-prone. My aim is to integrate other protocols into this crate as well, under the form of cargo features.

from wayland-rs.

In version 0.2 of the bindings to change the object in the closure of the callback, I had to actively use mutexes, the latest version uses queuing with match and the objects are borrowed automatically and mutexes are not needed. What is the lesser evil? Maybe there's a way to do it without mutexes, but it is faster than the queue?

Assume that library wayland-client rewrite to rust and distribute it as a dynamic library. Does this mean I would have to using rust bindings to rust library?

from wayland-rs.

Actually, it's not possible to rewrite the wayland-client binary library in rust and use it in production, because OpenGL implementations are directly linked to the C library and expect it to be the one in use. Replacing it with a Rust implementation would mean mimicking the internal structure of the C lib, which makes the whole thing useless.

The changes from callbacks to iterators was indeed meant to avoir this Arc & Mutex hell, that is absolutely not necessary. And anyway performances should not be an issue at all, the load caused by the communication between client & server is very low.

However, which objects are you talking about regarding them being borrowed automatically ? The EventIterator does not borrow anything...

from wayland-rs.

Well, not exactly borrowing: eventloop is single-threaded, and upon receiving the event executes 1 branch match in which sequentially modified wayland objects: be it a change in the position of the surface, attaching the buffer, causing damage, etc. Now, if it were possible to transfer this warranty on callbacks..

from wayland-rs.

You can build a system of callbacks, but it'll force you to have a huge lot of Arcs and Mutexes.

But you can also split your logic using several EventIterators. You can change the iterator associated with a wayland object using .set_evt_iterator() of the Proxy trait, which lets you have as much granularity as you want (and multithreading, if that is your goal).

from wayland-rs.

Arc & Mutex hell will be only when we want to modify the object from another thread. In other cases, you can use Rc. I understand that the code will be a little prettier if you use a queue instead of callbacks. But the bindings to the system library - one way or another they will be as part of something larger.

from wayland-rs.

No, you won't be able to use Rc. Because to ensure thread-safety, I must put Send + Sync bounds on the closures, and Rc is neither Send nor Sync.

Using an iterator-based approach allows me to align in behaviour with other crates, and is much more friendly to the borrow-checker and the way rust programs are built in general.

And due to the design of the wayland-client C library, it is not possible for me to offer both an iterator interface and a callback interface.

from wayland-rs.