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-boun...@lists.freedesktop.org> on behalf of
samuel ammonius <sfammon...@gmail.com>
Sent: Sunday, August 7, 2022 01:15
To: Igor Korot <ikoro...@gmail.com>
Cc: Thiago Macieira <thi...@kde.org>; Daniel Stone <dan...@fooishbar.org>;
wayland-devel@lists.freedesktop.org <wayland-devel@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
<sfammon...@gmail.com<mailto: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<mailto: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)
