Window positions under wayland

[JiDe Zhang]

Hi:

Is it that more people think that not allowed the window to set their position is better? I think that Wayland is better than X11 In this regard. It is correct to not let the window be set position, But some people will have doubts, because their know that some windows need to set their own position. We should pay attention to these needs and analyze what is the real reason their need for this interface, I don't think most of the window do not care about their positions, such as Chrome or Firefox, and some other commonly used applications, such as terminals, vscode, QtCreator, can not set positions is without any effect on them. In addition, there are some special windows, such as taskbar, message notifications, etc, They need to control the position of the window in screen, and they also need to set the layer of the window, such as the desktop window is always at the bottom, the taskbar window has been at the top. In fact such applications are usually provided by the desktop environment, the Wayland compositor can provide support for them, different desktop environments can fully control all their windows, this is right, they do not need Wayland to provide the interface of setting window positions.

In addition to the above two examples, some windows are neither part of the desktop environment and and does need to control the position of the window (I'm using "control" instead of "set" here because I think they just need a way to control the position of the window, rather than having to use something like the X11 way of setting window coordinates). For a example, there have a window, when the user drags it to the edge of the screen and releases the mouse, which will to hidden, display only a small part of the window at the edge of the screen, and when the mouse hover in this part of the exposed area, the window will full display. I have used some applications like this, I'm sorry I couldn't find a GIF picture about it, I hope you understand what kind of feature I described. I think such demand is reasonable, the demand can be implemented in other ways instead of providing the interface of the set window position. In the case I give an example, we can provide it with a allowable window to set its anchor on the screen, such as:

void handle_shell_surface_move_finished(wl_surface *s)
{
    QRegion visible_region = get_surface_visible_region_in_current_screen(s);
    QRect rect = visible_region.boundingRect();

    if (rect.y() > 0) {
         // Hidden the window to the top edge of the screen
         wl_shell_surface_anchors *screen_anchors = wl_shell_surface_get_screen_anchors(s);
         wl_shell_surface_anchors *window_anchors = wl_shell_surface_get_anchors(s);
         // Requires the bottom edge of the window to align with the top edge of the screen, and have 10px margins. You can only see the 10px height content at the bottom of the window on the screen.
         wl_shell_surface_request_anchors(window_anchors->bottom, screen_anchors->top, 10);
    }
}

I think this interface that is not setting absolute coordinates will be more friendly for the application, most similar needs can be solved using this like interface. Do you think so and do you have any other examples to introduce?

--
JiDe Zhang -- linuxdeepin.
________________________________
From: wayland-devel <wayland-devel-bounces at lists.freedesktop.org> on behalf of samuel ammonius <sfammonius at gmail.com>
Sent: Sunday, August 7, 2022 01:15
To: Igor Korot <ikorot01 at gmail.com>
Cc: Thiago Macieira <thiago at kde.org>; Daniel Stone <daniel at fooishbar.org>; wayland-devel at lists.freedesktop.org <wayland-devel at lists.freedesktop.org>
Subject: Re: Window positions under wayland

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 gmail.com<mailto:sfammonius at 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 <sfammonius at gmail.com<mailto:sfammonius at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20220808/11c13ce4/attachment-0001.htm>