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
The quickly-slapped together, but well tested ;) #125 was merged recently. This added notification reading support. Although this is exciting, I'd like it in a better state: a big list of random, unnamed fields in a tuple is not an ideal way to be deconstructing the message body.
We should have a Notification struct which implements Type instead, giving us access to all properties, along with their names.
This will require some additional work, especially related to how to (de)serialize key names in the receiving HashMap; ideally, we'd like to be able to deserialize this as an enum containing its internal data, like so:
for most of what you're saying, this commit covers it. Hints and afew other things weren't implemented there, but at the time, I believed, and somewhat still do, that it's out of scope. The only reason for the odilia-notify crate existing is to serve the needs of odilia when it comes to capturing notifications. I rejected that particular commit though, for the reason outlined above, and also because I thought it would add more bloat. In any case, work from this can begin by either reverting the commit after it, or cherry picking the commit I just linked and solving merge conflicts. The rest of what you said, aka hints as enums and other such things, can continue from there.
TTWNO
linked a pull request
Mar 7, 2024
that will
close
this issue
The quickly-slapped together, but well tested ;) #125 was merged recently. This added notification reading support. Although this is exciting, I'd like it in a better state: a big list of random, unnamed fields in a tuple is not an ideal way to be deconstructing the message body.
We should have a
Notification
struct which implementsType
instead, giving us access to all properties, along with their names.This will require some additional work, especially related to how to (de)serialize key names in the receiving
HashMap
; ideally, we'd like to be able to deserialize this as an enum containing its internal data, like so:That will give us a much more flexible notification module.
The text was updated successfully, but these errors were encountered: