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 <sfammon...@gmail.com> 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 <sfammon...@gmail.com>
> 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)
>>
>
