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)
>
