Window positions under wayland

samuel ammonius sfammonius at
Sat Aug 6 17:15:42 UTC 2022

No one responded to my last email, so I'll just assume it was because
everyone aggeed with it and not because it was so horribly structured that
no one understood a thing I was saying :).

It would be possible to redesign Wayland following the principles you
> have described. No-one is doing this, however.
If I added this feature through git, would it be accepted? It would just be
"void wl_surface_request_position(wl_surface *surface, unsigned int x,
unsigned int y);"

On Fri, Aug 5, 2022 at 8:14 PM samuel ammonius <sfammonius at> wrote:

> Sorry, I just read over my last email and realized that I didn't even
> state what I was trying
> to say. I meant my last suggestion of letting the compositor handle the
> resize event. I was
> just giving some reasons as to why it may be the best solution.
> On Fri, Aug 5, 2022 at 6:32 PM samuel ammonius <sfammonius at>
> wrote:
>> I don't understand why we're all asking if it should be up to the
>> compositor or app to set a
>> window's position. The only correct answer is that it should be up to the
>> user, so I don't
>> see what's wrong with my suggestion of a "set window size request"
>> function. Waylands
>> idea of not letting apps set their window position because it thinks it
>> knows better is very
>> similar to what's wrong with commercial operating systems nowadays, and
>> it's probably
>> why many of us left Windows. For example, you could only disable "live
>> security" in the
>> settings for up to 10 minutes to speed up a download, and you aren't
>> given an option to
>> never update the operating system (if you wanted to increase the life
>> expectancy of your
>> SSD, for example).
>> The only compromise in this case that truly gives users full control is
>> one where users
>> get to configure their compositor to either.
>> 1) Allow apps to freely set their positions
>> 2) Have the window manager make them start in the center or at their last
>> location
>> 3) Use the position apps request to make smart decisions about how the
>> app should
>>      be placed (for example, if an app always starts at (100, 100) on a
>> 1000x700 monitor,
>>      but the user has recently switched to a new 3000x2400 monitor, then
>> the app can be
>>      placed at (300, 300))
>> The user can also configure individual apps to start in different ways if
>> they chose to
>> allow apps to pick their positions, or some compositors can even give
>> users the option to
>> apply the above to certain apps separately.
>> This design gives everyone 200% of what they asked for. Compositors can
>> obtain even
>> more information about how a window should be placed, and windows can
>> choose their
>> own locations knowing that the compositor will optimize that position for
>> the users screen
>> to make sure they don't make any mistakes. I don't see a single thing
>> that this takes away
>> from Waylands current design.
>> Also, as Igor said, flags on how the compositor should interpret the size
>> request would be
>> a great feature as well. There could be flags for priority,
>> relative/absolute positioning, or
>> any number of other things that could be added in the future. (Qt uses a
>> genius flag system,
>> where each flag is double the last one so they can just be added to each
>> other and no two
>> combinations of them will match. For example: NO_FLAGS = 0x00, FLAG_A =
>> 0x01,
>> FLAG_B = 0x02, FLAG_C = 0x04, FLAG_D = 0x08, FLAG_E = 0x10, FLAG_F =
>> 0x20, etc...,
>> and then the flags could be used like "FLAG_B | FLAG_E" ("|" is an
>> uncommon C/C++
>> feature for adding constants without optimization). It's probably
>> irrelevant but it's really cool)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list