Arnold Loubriat

@luukvanderduim > The StateChanged signal (see: Event.xml) uses 'string' to encode the state, (NOT by a u32 representing the enum variant! as one might expect) In atspi State's Rust representation...

> You mentioned we get State and Role were obtained from EventBody , I presume you meant the Message's body then For the `StateChanged` signal a `State` has to fit...

Sorry @luukvanderduim I missed your last comment. I think we are both on the same track now! It's not clear what's the solution for me either, maybe we should open...

@TTWNO I'm definitely not advocating for ditching all the work already done by @luukvanderduim with this PR. Maybe strum will be necessary to fully support features such as fine-grained event...

@TTWNO Thanks for all the efforts you put into this! Unfortunately this PR seem to contain way too many unrelated changes for me to review right now, but I checked...

No we currently don't use these, although I was eventually planning on doing so. If feature-gating these convertions is the only way forward, I'm fine with what you propose.

For now we create messages to emit signals by hand. Since the code is already there I will probably leave it as is if relying on atspi would bring strum.

So there is now no easy way to emit a state change event right? With the old `EventBody` type, the `kind` field was generic over `Serialize` so I could put...

FYI in AccessKit we need textual representation of states to emit signals such as `object:state-changed`. The code could probably be refactored to take advantage of serde. However, we now have...

I will try inside `accesskit_unix` to make use of more types from `atspi-common` so that `serde` can take care of all these string representations. Like I said in the past,...