Semantics of getters/setters and events? about winit

[kchibisov]

On X11, the server is asynchronous, and might receive another event (from the user). (Or might just misbehave, and not set the title?)

It could be not applied instantly. In general, relying that title was actually changed is not a great idea because it's not guaranteed, etc, etc.

I'd just suggest that we model methods that are crucial, like Window::request_inner_size as close to their real semantics as possible, and for the rest we do best effort when it comes to consistency.

[daxpedda]

Is that how it works on the other platforms too? And for all the other methods?

Not for Web, where any getter method will always return the current true value regardless of what the last thing is the user did. Though more often then not this turns out to look like 1. anyway because on Web most things are updated immediately.

I see that we have request_inner_size, I think because it works like option 2 on some platforms (X11? Windows?), ...

Yes, additionally because there is no guarantee that this is set to the value the user requested because e.g. its not allowed to be that big/small, or in the case of Web there is no way to accurately set the size, it might be a pixel off.

can and should we change that to be more consistent?

I think it would be best to basically make a list of every single method and let backend maintainers answer this question for every method. Though this is probably a lot of work.

But yes, I also believe we should be consistent here and document it when we are not, which we did in some places.

---

I also agree that we should stick with option 1., as long as viable, e.g. consistent on all platforms. Though it might not make sense for functions that can't predict what the outcome might be, e.g. with request_inner_size().

[kchibisov]

Well, reporting old value could be just incorrect because the windowing system could deny what you did, so you use something wrong and e.g. fail in validation, etc.

In general, only platforms where things are entirely client side can do that correctly and do 1 or 3. So I guess wayland/macOS can do so.

You also can not really do e.g. 3 unless you allow re-entrance.

About the option 1, it works the way you'd expect only on Wayland, the rest likely can reject it on server and you'll desync unless you try to correct the user. And the user could also easily enter the update cycle because they want to prevent the server change. Though, you can end up with that in a lot of cases right now anyway and we shouldn't prevent from it.

[madsmtm]

Rough conclusion from today's meeting: Option 1 has the desired semantics.

So taking the simpler example of set_title, the following assert should succeed:

window.set_title("foo");
assert_eq!(window.title(), "foo");

There are, naturally, cases where it might not, where the title might be updated in between those two calls, such as:

• On web, when running from a service worker, the main thread (or another service worker, or some JS somewhere) might race setting a new title.
• On macOS, when running from a thread that is not the main thread, and other user code sets the title.
• On X11, the server is asynchronous, and might receive another event (from the user). (Or might just misbehave, and not set the title?)
• On all platforms, if setting the title concurrently from two threads (I think?)

The point is not to rule out the above cases, the point is that the title is immediately available in the getter.

In short, the desired behaviour is that you will never get an old value, though you might get a newer value than the one you just set.

Does that match your understanding?

---

I think instead of making a list of which methods play by this rule, and which ones doesn't, I'm gonna make a test case or some feature-flagged assertions, or something, to ensure that this is the behaviour, and to make it easy to test if it is (in the future too).