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

[Steve (YiLiang) Zhou]

Thanks all you guys,
So when it come to my issue, there is no way to adjust the position of
my app which is developed with qt4 and upgraded to qt5 now ,right?
Or can I create a wayland compositor and attach it to my qt window ?


Thanks and Best Regards
Steve Zhou


-----Original Message-----
From: Pekka Paalanen [mailto:ppaalanen at gmail.com] 
Sent: Tuesday, August 12, 2014 1:33 AM
To: Nils Chr. Brause
Cc: Giulio Camuffo; Rutledge Shawn; Steve (YiLiang) Zhou; Pier Luigi; Qt
Project; wayland
Subject: Re: [Interest] qt5 window setGeometry and move not work in
wayland platform

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

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.