Ferdinand Schober

Apparently, I missed this when writing the example.

> Apparently, I missed this when writing the example. And GNOME does not seem to verify this, but the plasma portal does. So that is probably, why I missed it.

There is this: ``` barrier_id (u) The barrier id of the barrier that triggered. If the value is nonzero, it matches the barrier id as specified in [org.freedesktop.portal.InputCapture.SetPointerBarriers](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.InputCapture.html#org-freedesktop-portal-inputcapture-setpointerbarriers). If the...

I'm also just realizing, that this is not 100% correct in it's current state. It should really be an `Option` According to the documentation, zero means "the barrier could not...

> > I'm not quite sure what "barrier could not be determined" is supposed to mean... > > it's basically a cop-out behavior, sorry :) But it basically means "yes,...

I am referring to barrier-clients in a barrier use case. You would need some sort of `Map` that maps the barrier that was activated to the client that is associated...

The case you describe makes sense but it would also be possible to just report the previous barrier_id imo.

> I feel like I'm being dense: the barrier id is just a number, there's no guarantee they're unique (except within the client). So you already cannot rely on the...

> so what is the tldr here? Sorry for the late reply TLDR is: We want `Option` to comply with the spec, as long as zbus can correctly deserialize that...

> I would suggest to do a proper `enum` and implement serialize/deserialize, from a user perspective `Option` does not give any info and most people will just flat it into...