Comments (9)
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 Arc
s and Mutex
es.
But you can also split your logic using several EventIterator
s. 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.
Related Issues (20)
- wayland-client: add easier way to create object from wl_proxy pointer HOT 1
- Proxy tags HOT 3
- wayland-sys vendor feature (request for a `wayland-src` crate) HOT 2
- how to convert a wl_surface pointer to WlSurface HOT 2
- WlRegistry.bind always outputs WlRegistry HOT 5
- Failed build when running with coverage on stable Rust HOT 1
- RFC: Rethinking the design of the crates API HOT 8
- Unable to copy to buffer using ZwlrScreencopyFrameV1 HOT 1
- Apparent misuse of scoped-tls, only appearing on a Raspberry Pi HOT 19
- Feature to avoid usage of `memfd_create` HOT 3
- Backend+client API to take control of proxies HOT 3
- wayland-protocols 0.32 got published without protocols/ HOT 2
- Attaching None to a surface influences surface configuration HOT 3
- illumos is not supported HOT 4
- surface.attach(None, 0, 0) doesn't allow for a re-map of the layer surface. HOT 3
- wayland-server: There is no way to bind to a passed socket FD HOT 1
- Regression in foreign object management
- String arguments should be CString
- Unable to compile my project for linux xorg using winit HOT 4
- Read cursor file directly instead of first to Vec and then through xcursor
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wayland-rs.