Winit: Window starting position

[chrisduerr]

I'm not sure about support of other platforms, but I believe at least XCB should support setting the starting position of a Window, so in theory it should be possible to have a with_position method on at least the X11 backend.

Most of the other functions relevant at startup have a matching with_* function call for their set_* calls, so I'm not sure if this is due to a lack of support for some platforms, however it seems there are some clear advantages for the platforms that support it since it allows spawning the window without things jumping around.

[repi]

A with_position would indeed be nice.

Currently we work around it by directly setting the position of the window with window.set_position, which works but is less elegant and a bit more work.

[chrisduerr]

The big issue with window.set_position is that it will resize the window, no matter how early you do it. So unfortunately that creates this flickering effect where the window is first spawned at one size and then later changed to another.

[Osspial]

This should work on all non-Wayland desktop platforms, so I'd be fine with this getting added.

[Abendstolz]

As the API was changed lately (commit) and there is only a set_outer_position I assume there should only be a with_outer_position.

Is that assumption correct?

Another question: As by @Osspial's comment this doesn't work on a Wayland desktop - does or should set_outer_position? Because the "platform-specific" part of the docs there only mention iOS.

[vberger]

Another question: As by @Osspial's comment this doesn't work on a Wayland desktop - does or should set_outer_position? Because the "platform-specific" part of the docs there only mention iOS.

Wayland apps cannot control their location on the desktop, at all.

[Abendstolz]

Another question: As by @Osspial's comment this doesn't work on a Wayland desktop - does or should set_outer_position? Because the "platform-specific" part of the docs there only mention iOS.

Wayland apps cannot control their location on the desktop, at all.

So should that be documented in set_outer_position as well or is it considered common knowledge for anyone targeting Wayland? (Which you might do without yourself knowing)

[felixrabe]

It should be documented, because using winit should not require reading up on surprising implementation differences on different platforms. Everything that could cause someone to later open an issue along the lines of "why does xyz not work as expected?" should be explicitly documented.

Assume someone primarily developed the app on one platform, then later decides to try running it on another.

[chrisduerr]

Usually better than documenting things is encoding it in the API. So if this doesn't work on Wayland, it just shouldn't be implemented for that platform.

[vberger]

@chrisduerr The choice between x11 and wayland is done at runtime, so we cannot really do anything more than the method doing nothing on wayland, apart maybe returning an error?

Though I tend to think it's the kind of functionality that would not really be a big issue if it just does not work on some platforms.

[chrisduerr]

Oh yeah, I always forget about the Wayland/X11 troubles where everything has to be done at runtime.

I personally find it very difficult to have things only documented if there's an alternative, because often when using code completion or you're just skimming docs for specific methods you'll never find these limitations. When stuff then suddenly hard crashes on certain platforms that gets a bit problematic I think.

If the method just does nothing, that's not a hard crash at least, but that might cause even more confusion when the issue is reported and it might take a lot longer until it is reported.

Returning an error would at least directly encode the potential of runtime failure into the API, but obviously make the API inconvenient to use on other platforms.

Ultimately I can't say what the best choice is in general and I think this has to be decided on a case by case basis, but it generally seems like something that goes against the grain of Rust, where most things are encoded into the compile time API checks.

[Osspial]

The best solution I can think of right now is to have WindowBuilder::with_outer_position return Result<WindowBuilder, NotSupportedError>, which forces people to deal with the possibility of an error when they call that function. That doesn't deal with people setting the field in WindowAttributes, though.

EDIT: Really set_outer_position should also return a NotSupportedError on Wayland. Looks like I forgot to add that in the original error message commit.

[felixrabe]

Speaking of Result – I think there is too much unwrap in winit. Has there been some discussion of this previously? Could we make winit 0.20 also a "don't panic" (or as little as possible) release? (Edit: Opened #971 for further discussion of this.)

[chrisduerr]

Could we make winit 0.20 also a "don't panic" (or as little as possible) release?

I'd just like to say that extending the 0.20 scope further and further likely isn't a great idea. Though limiting the panics directly in winit feels like a good thing.

[murarth]

How can we get the ball rolling on this? Would it be okay if I submitted a PR creating the public API, with an implementation on X11, and created a tracking issue for implementation on other platforms?

The best solution I can think of right now is to have WindowBuilder::with_outer_position return Result<WindowBuilder, NotSupportedError>, which forces people to deal with the possibility of an error when they call that function. That doesn't deal with people setting the field in WindowAttributes, though.

I think that, while returning Result may be suitable for Window::set_outer_position, it would significantly hamper the method-chaining usage of WindowBuilder. It would be better, I think, just to add a note in the docs for WindowBuilder::with_outer_position about Wayland-specific behavior. There are a number of Window methods with "no effect" notes like this.