You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My Odilia PR #116 is causing me serious headaches trying to send events down the pipe. Is it really necessary that an Event be build from a zbus::Message?
Based on what info we have, it should be fairly easy to have each event be a struct with the names of fields. For example:
This makes creating new events and sending them through a function like events::dispatch in Odilia much easier if the innermost type can be easily filled like this with simple public fields.
I also see that Cache::* and Available methods are written manually, which shouldn't be necessary under the new system. I'll basically wrire a macro that generates a slightly modified zvariant::Type implementation for each event.
It would also be nice if any event type could be trivially converted into a Signal that could be sent over DBus. This could simplify a lot of tests.
My Odilia PR #116 is causing me serious headaches trying to send events down the pipe. Is it really necessary that an Event be build from a
zbus::Message
?Based on what info we have, it should be fairly easy to have each event be a struct with the names of fields. For example:
This makes creating new events and sending them through a function like
events::dispatch
in Odilia much easier if the innermost type can be easily filled like this with simple public fields.I also see that Cache::* and Available methods are written manually, which shouldn't be necessary under the new system. I'll basically wrire a macro that generates a slightly modified
zvariant::Type
implementation for each event.It would also be nice if any event type could be trivially converted into a Signal that could be sent over DBus. This could simplify a lot of tests.
Imagine code like this in tests:
The text was updated successfully, but these errors were encountered: