[Interest] qt5 window setGeometry and move not work in wayland platform

[Pekka Paalanen]

On Mon, 11 Aug 2014 18:49:50 +0200
"Nils Chr. Brause" <nilschrbrause at gmail.com> wrote:

> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo <giuliocamuffo at gmail.com>
> wrote:
> 
> > The problem is that windows don't always have a meaningful position.
> > If a window is shown on two outputs at the same time, maybe one of
> > which a remote one, what is the window position? And what is the
> > position of a window rotated 45 degrees?
> >
> 
> Since the question about absolute positioning of windows comes up every now
> and then (and probably will continue to do so for the next few years), I
> thought about a possible way to fix this.
> 
> We could create a new interface, that puts an unrotated rectangle around a
> window (which could be transformed in whatever way), that is just big
> enough to fit in the whole window. The upper left corner of this rectangle
> could then be defined as its "position", which could be read and set by the
> user. The size of this rectangle could also be of interest of the user, but
> of course not be set.
> 
> Since a window could be on multiple outputs, there would be the need for
> one instance of this interface for every output and every window. These
> could maybe be created and destroyed with events (whenever a window appears
> or disappears on an output).

Just... no.

It is a very deliberate design choice to not expose window position.

Your idea for a bounding box might seem like it could work at first,
but what can an app actually do with it? The app won't have any idea
of how the actual window is really mapped to an output. So far we
are using rectangular outputs, but that does not need to be the case
either.

Window appearance is not limited to just one per output, in fact it
has nothing to do with outputs at all. A window can appear any
number of times anywhere, and with any transformation, if the
compositor so decides. Any of these views may or may not allow user
interaction, e.g. pointer input.

You would have a lot of work communicating all that to the clients,
even if you used the bounding box approach, and it would be full of
races or round-trips, likely both.

Yet another reason to not implement a coordinate based window
positioning driven by clients is that clients do not know what else
is on screen, what shape is the screen, etc.

Just say no to all attempts for such generic positioning, and look
at the actual use case behind it on *why* would this particular case
want to do something like this, what is the real meaning behind it,
and think how the compositor can do the job much better when it
knows what the intention is.


Thanks,
pq