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

[Steve (YiLiang) Zhou]

Dear all,

My app has a mainwindow and a QDialog which is a child of mainwindow.
And I want to set the app to the position 0,0.

I use both setGeometry and move to 0,0. No luck , both failed. The
window's position is unfixed and may appear to anywhere on the screen.

My Qt version :5.2.2

Some codes in my app:

Widget is my qdialog this is my mainwindow.



widget->setStyleSheet("background:transparent;");

widget->setAttribute(Qt::WA_TranslucentBackground);

widget->setWindowFlags(Qt::FramelessWindowHint);

this->setStyleSheet("background:transparent;");

this->setAttribute(Qt::WA_TranslucentBackground);

this->setWindowFlags(Qt::FramelessWindowHint
|Qt::WindowStaysOnTopHint );

this->move(0,0);

widget->move(0,0);





has anybody met this before?

BTW: I use wl_egl_window_create a shell window and
wl_egl_window_resize set the position, it can be set to 0,0.







Thanks and Best Regards

Steve Zhou




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.

[Pier Luigi]

Clients don't get to set window position with Wayland.
You should write a Wayland protocol for that but you need a compositor
that speaks that protocol.

2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
> Dear all,
>
> My app has a mainwindow and a QDialog which is a child of mainwindow. And I
> want to set the app to the position 0,0.
>
> I use both setGeometry and move to 0,0. No luck , both failed. The window’s
> position is unfixed and may appear to anywhere on the screen.
>
> My Qt version :5.2.2
>
> Some codes in my app:
>
> Widget is my qdialog this is my mainwindow.
>
>
>
> widget->setStyleSheet("background:transparent;");
>
> widget->setAttribute(Qt::WA_TranslucentBackground);
>
> widget->setWindowFlags(Qt::FramelessWindowHint);
>
> this->setStyleSheet("background:transparent;");
>
> this->setAttribute(Qt::WA_TranslucentBackground);
>
> this->setWindowFlags(Qt::FramelessWindowHint |Qt::WindowStaysOnTopHint
> );
>
> this->move(0,0);
>
> widget->move(0,0);
>
>
>
>
>
> has anybody met this before?
>
> BTW: I use wl_egl_window_create a shell window and wl_egl_window_resize
> set the position, it can be set to 0,0.
>
>
>
>
>
>
>
> Thanks and Best Regards
>
> Steve Zhou
>
>
>
> 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.
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-***@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



--
Out of the box experience
http://www.maui-project.org/

[Steve (YiLiang) Zhou]

Hi Pier,
Thanks for your quick reply, your explain is very useful. But forgive me to bother you again, could you please give me an example or a link of how to achieve that?

Thanks and Best Regards
Steve Zhou


-----Original Message-----
From: Pier Luigi [mailto:***@gmail.com]
Sent: Monday, August 11, 2014 3:11 PM
To: Steve (YiLiang) Zhou
Cc: ***@qt-project.org; wayland
Subject: Re: qt5 window setGeometry and move not work in wayland platform

Clients don't get to set window position with Wayland.
You should write a Wayland protocol for that but you need a compositor that speaks that protocol.

2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
> Dear all,
>
> My app has a mainwindow and a QDialog which is a child of mainwindow.
> And I want to set the app to the position 0,0.
>
> I use both setGeometry and move to 0,0. No luck , both failed. The
> window’s position is unfixed and may appear to anywhere on the screen.
>
> My Qt version :5.2.2
>
> Some codes in my app:
>
> Widget is my qdialog this is my mainwindow.
>
>
>
> widget->setStyleSheet("background:transparent;");
>
> widget->setAttribute(Qt::WA_TranslucentBackground);
>
> widget->setWindowFlags(Qt::FramelessWindowHint);
>
> this->setStyleSheet("background:transparent;");
>
> this->setAttribute(Qt::WA_TranslucentBackground);
>
> this->setWindowFlags(Qt::FramelessWindowHint
> |Qt::WindowStaysOnTopHint );
>
> this->move(0,0);
>
> widget->move(0,0);
>
>
>
>
>
> has anybody met this before?
>
> BTW: I use wl_egl_window_create a shell window and
> wl_egl_window_resize set the position, it can be set to 0,0.
>
>
>
>
>
>
>
> Thanks and Best Regards
>
> Steve Zhou
>
>
>
> 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.
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-***@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



--
Out of the box experience
http://www.maui-project.org/

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

[Agocs Laszlo]

Hello,

When it comes to child windows with transient parents, it should be supported. (wl_shell_surface::set_transient)
It of course needs support both from the platform plugin and the compositor. Some time back it used to work both with QtCompositor and Weston. Not sure what's the situation today.

Best regards,
Laszlo

From: interest-bounces+laszlo.agocs=***@qt-project.org [interest-bounces+laszlo.agocs=***@qt-project.org] on behalf of Steve (YiLiang) Zhou [***@telecomsys.com]
Sent: Monday, August 11, 2014 9:15 AM
To: Pier Luigi
Cc: ***@qt-project.org; wayland
Subject: Re: [Interest] qt5 window setGeometry and move not work in wayland platform

Hi Pier,
Thanks for your quick reply, your explain is very useful. But forgive me to bother you again, could you please give me an example or a link of how to achieve that?

Thanks and Best Regards
Steve Zhou


-----Original Message-----
From: Pier Luigi [mailto:***@gmail.com]
Sent: Monday, August 11, 2014 3:11 PM
To: Steve (YiLiang) Zhou
Cc: ***@qt-project.org; wayland
Subject: Re: qt5 window setGeometry and move not work in wayland platform

Clients don't get to set window position with Wayland.
You should write a Wayland protocol for that but you need a compositor that speaks that protocol.

2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
> Dear all,
>
> My app has a mainwindow and a QDialog which is a child of mainwindow.
> And I want to set the app to the position 0,0.
>
> I use both setGeometry and move to 0,0. No luck , both failed. The
> window’s position is unfixed and may appear to anywhere on the screen.
>
> My Qt version :5.2.2
>
> Some codes in my app:
>
> Widget is my qdialog this is my mainwindow.
>
>
>
> widget->setStyleSheet("background:transparent;");
>
> widget->setAttribute(Qt::WA_TranslucentBackground);
>
> widget->setWindowFlags(Qt::FramelessWindowHint);
>
> this->setStyleSheet("background:transparent;");
>
> this->setAttribute(Qt::WA_TranslucentBackground);
>
> this->setWindowFlags(Qt::FramelessWindowHint
> |Qt::WindowStaysOnTopHint );
>
> this->move(0,0);
>
> widget->move(0,0);
>
>
>
>
>
> has anybody met this before?
>
> BTW: I use wl_egl_window_create a shell window and
> wl_egl_window_resize set the position, it can be set to 0,0.
>
>
>
>
>
>
>
> Thanks and Best Regards
>
> Steve Zhou
>
>
>
> 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.
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-***@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



--
Out of the box experience
http://www.maui-project.org/

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.

[Rutledge Shawn]

On 11 Aug 2014, at 9:10 AM, Pier Luigi wrote:
(top-posting fixed)
> 2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
>> Dear all,
>>
>> My app has a mainwindow and a QDialog which is a child of mainwindow. And I
>> want to set the app to the position 0,0.
>>
>> I use both setGeometry and move to 0,0. No luck , both failed. The window’s
>> position is unfixed and may appear to anywhere on the screen.

I was wondering about that too. I understand that it's generally good policy to leave positioning of generic windows up to the window manager, but sometimes you want to write a dock or taskbar which anchors itself to screen edges, and can animate in and out of view; or a splash screen which is centered on one screen. What is the right way to do that on Wayland?

> Clients don't get to set window position with Wayland.
> You should write a Wayland protocol for that but you need a compositor
> that speaks that protocol.

Has it not yet been done in existing compositors such as the Qt one or in Weston?

[Giulio Camuffo]

2014-08-11 12:20 GMT+03:00 Rutledge Shawn <***@digia.com>:
>
> On 11 Aug 2014, at 9:10 AM, Pier Luigi wrote:
> (top-posting fixed)
>> 2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
>>> Dear all,
>>>
>>> My app has a mainwindow and a QDialog which is a child of mainwindow. And I
>>> want to set the app to the position 0,0.
>>>
>>> I use both setGeometry and move to 0,0. No luck , both failed. The window’s
>>> position is unfixed and may appear to anywhere on the screen.
>
> I was wondering about that too. I understand that it's generally good policy to leave positioning of generic windows up to the window manager, but sometimes you want to write a dock or taskbar which anchors itself to screen edges, and can animate in and out of view; or a splash screen which is centered on one screen. What is the right way to do that on Wayland?

The right way is to have a protocol designed for that. A taskbar
should use some taskbar_protocol with a request like
put_on_edge(edge), and the compositor will then move the surface on
the edge and do slide in/out or whatever effect it wants to.

>
>> Clients don't get to set window position with Wayland.
>> You should write a Wayland protocol for that but you need a compositor
>> that speaks that protocol.
>
> Has it not yet been done in existing compositors such as the Qt one or in Weston?

Not in QtCompositor. Weston has a private protocol to set some surface
as a panel, but it is private and weston-specific.

--
Giulio


>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

[Rutledge Shawn]

On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote:

> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn <***@digia.com>:
>>
>> On 11 Aug 2014, at 9:10 AM, Pier Luigi wrote:
>> (top-posting fixed)
>>> 2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
>>>> Dear all,
>>>>
>>>> My app has a mainwindow and a QDialog which is a child of mainwindow. And I
>>>> want to set the app to the position 0,0.
>>>>
>>>> I use both setGeometry and move to 0,0. No luck , both failed. The window’s
>>>> position is unfixed and may appear to anywhere on the screen.
>>
>> I was wondering about that too. I understand that it's generally good policy to leave positioning of generic windows up to the window manager, but sometimes you want to write a dock or taskbar which anchors itself to screen edges, and can animate in and out of view; or a splash screen which is centered on one screen. What is the right way to do that on Wayland?
>
> The right way is to have a protocol designed for that. A taskbar
> should use some taskbar_protocol with a request like
> put_on_edge(edge), and the compositor will then move the surface on
> the edge and do slide in/out or whatever effect it wants to.

I understand the advantage of taking a higher-level approach. But then someone thinks of something for which the scenario-specific protocol doesn't suffice. If windows could move themselves, it might be more flexible. It may be too low-level, but it's hard to think of any other protocol that is universal enough, which I suppose is why it's not standardized.

What about when a window provides its own "skinned" window decorations: there will probably be some area in which you can drag to move the window, as you normally can on the titlebar. Is there another protocol for that? How would that be different from a generic protocol which windows could use to position themselves?

[Giulio Camuffo]

2014-08-11 13:29 GMT+03:00 Rutledge Shawn <***@digia.com>:
>
> On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote:
>
>> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn <***@digia.com>:
>>>
>>> On 11 Aug 2014, at 9:10 AM, Pier Luigi wrote:
>>> (top-posting fixed)
>>>> 2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
>>>>> Dear all,
>>>>>
>>>>> My app has a mainwindow and a QDialog which is a child of mainwindow. And I
>>>>> want to set the app to the position 0,0.
>>>>>
>>>>> I use both setGeometry and move to 0,0. No luck , both failed. The window’s
>>>>> position is unfixed and may appear to anywhere on the screen.
>>>
>>> I was wondering about that too. I understand that it's generally good policy to leave positioning of generic windows up to the window manager, but sometimes you want to write a dock or taskbar which anchors itself to screen edges, and can animate in and out of view; or a splash screen which is centered on one screen. What is the right way to do that on Wayland?
>>
>> The right way is to have a protocol designed for that. A taskbar
>> should use some taskbar_protocol with a request like
>> put_on_edge(edge), and the compositor will then move the surface on
>> the edge and do slide in/out or whatever effect it wants to.
>
> I understand the advantage of taking a higher-level approach. But then someone thinks of something for which the scenario-specific protocol doesn't suffice. If windows could move themselves, it might be more flexible. It may be too low-level, but it's hard to think of any other protocol that is universal enough, which I suppose is why it's not standardized.

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?

>
> What about when a window provides its own "skinned" window decorations: there will probably be some area in which you can drag to move the window, as you normally can on the titlebar. Is there another protocol for that? How would that be different from a generic protocol which windows could use to position themselves?

wl_shell_surface/xdg_surface have a "move" request. The clients call
that and then the compositor actually does the moving.

[Rutledge Shawn]

On 11 Aug 2014, at 12:57 PM, Giulio Camuffo wrote:

> 2014-08-11 13:29 GMT+03:00 Rutledge Shawn <***@digia.com>:
>>
>> On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote:
>>
>>> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn <***@digia.com>:
>>>>
>>>> On 11 Aug 2014, at 9:10 AM, Pier Luigi wrote:
>>>> (top-posting fixed)
>>>>> 2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
>>>>>> Dear all,
>>>>>>
>>>>>> My app has a mainwindow and a QDialog which is a child of mainwindow. And I
>>>>>> want to set the app to the position 0,0.
>>>>>>
>>>>>> I use both setGeometry and move to 0,0. No luck , both failed. The window’s
>>>>>> position is unfixed and may appear to anywhere on the screen.
>>>>
>>>> I was wondering about that too. I understand that it's generally good policy to leave positioning of generic windows up to the window manager, but sometimes you want to write a dock or taskbar which anchors itself to screen edges, and can animate in and out of view; or a splash screen which is centered on one screen. What is the right way to do that on Wayland?
>>>
>>> The right way is to have a protocol designed for that. A taskbar
>>> should use some taskbar_protocol with a request like
>>> put_on_edge(edge), and the compositor will then move the surface on
>>> the edge and do slide in/out or whatever effect it wants to.
>>
>> I understand the advantage of taking a higher-level approach. But then someone thinks of something for which the scenario-specific protocol doesn't suffice. If windows could move themselves, it might be more flexible. It may be too low-level, but it's hard to think of any other protocol that is universal enough, which I suppose is why it's not standardized.
>
> 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?

On X11 (and other window systems) all outputs are mapped into the "virtual desktop" space, side-by-side or overlapping or whatever, so that there is a unified coordinate system. On Wayland there is not this assumption?

> And what is the
> position of a window rotated 45 degrees?

Something could be made up; perhaps the position should always be the centroid instead of the upper-left? (although in other use cases that would be less convenient) Rotation doesn't make sense without a center of rotation either.

>> What about when a window provides its own "skinned" window decorations: there will probably be some area in which you can drag to move the window, as you normally can on the titlebar. Is there another protocol for that? How would that be different from a generic protocol which windows could use to position themselves?
>
> wl_shell_surface/xdg_surface have a "move" request. The clients call
> that and then the compositor actually does the moving.

So interactive moving only, but nothing to ask programmatically for a window to be moved by some delta.

[Giulio Camuffo]

2014-08-11 16:12 GMT+03:00 Rutledge Shawn <***@digia.com>:
>
> On 11 Aug 2014, at 12:57 PM, Giulio Camuffo wrote:
>
>> 2014-08-11 13:29 GMT+03:00 Rutledge Shawn <***@digia.com>:
>>>
>>> On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote:
>>>
>>>> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn <***@digia.com>:
>>>>>
>>>>> On 11 Aug 2014, at 9:10 AM, Pier Luigi wrote:
>>>>> (top-posting fixed)
>>>>>> 2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
>>>>>>> Dear all,
>>>>>>>
>>>>>>> My app has a mainwindow and a QDialog which is a child of mainwindow. And I
>>>>>>> want to set the app to the position 0,0.
>>>>>>>
>>>>>>> I use both setGeometry and move to 0,0. No luck , both failed. The window’s
>>>>>>> position is unfixed and may appear to anywhere on the screen.
>>>>>
>>>>> I was wondering about that too. I understand that it's generally good policy to leave positioning of generic windows up to the window manager, but sometimes you want to write a dock or taskbar which anchors itself to screen edges, and can animate in and out of view; or a splash screen which is centered on one screen. What is the right way to do that on Wayland?
>>>>
>>>> The right way is to have a protocol designed for that. A taskbar
>>>> should use some taskbar_protocol with a request like
>>>> put_on_edge(edge), and the compositor will then move the surface on
>>>> the edge and do slide in/out or whatever effect it wants to.
>>>
>>> I understand the advantage of taking a higher-level approach. But then someone thinks of something for which the scenario-specific protocol doesn't suffice. If windows could move themselves, it might be more flexible. It may be too low-level, but it's hard to think of any other protocol that is universal enough, which I suppose is why it's not standardized.
>>
>> 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?
>
> On X11 (and other window systems) all outputs are mapped into the "virtual desktop" space, side-by-side or overlapping or whatever, so that there is a unified coordinate system. On Wayland there is not this assumption?

I'm not sure I follow. How does that fix the problem of the same
window being shown at the same time at 10x10 of an output and at 0x0
of another one?

>
>> And what is the
>> position of a window rotated 45 degrees?
>
> Something could be made up; perhaps the position should always be the centroid instead of the upper-left? (although in other use cases that would be less convenient) Rotation doesn't make sense without a center of rotation either.
>
>>> What about when a window provides its own "skinned" window decorations: there will probably be some area in which you can drag to move the window, as you normally can on the titlebar. Is there another protocol for that? How would that be different from a generic protocol which windows could use to position themselves?
>>
>> wl_shell_surface/xdg_surface have a "move" request. The clients call
>> that and then the compositor actually does the moving.
>
> So interactive moving only, but nothing to ask programmatically for a window to be moved by some delta.

Actually, both. Clients can ask the compositor to move a surface by a
dx,dy when attaching a buffer.

[Thiago Macieira]

On Monday 11 August 2014 16:34:48 Giulio Camuffo wrote:
> > So interactive moving only, but nothing to ask programmatically for a
> > window to be moved by some delta.
> Actually, both. Clients can ask the compositor to move a surface by a
> dx,dy when attaching a buffer.

The compositor is free to ignore such a request, though.

General windows don't need to know where they are and thus don't need to tell
the compositor where they should be. The compositor has placed them where they
fit and, if the user wants to move it, the user will initiate the moving.

That does not apply to desktop fixtures, like docks and taskbars. As agreed
back in 2012, those fixtures are considered extensions of the compositor
itself. The best way to accomplish them is to modify the compositor to draw
them where the compositor wants to.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[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:***@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" <***@gmail.com> wrote:

> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo
> <***@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.

[Giulio Camuffo]

2014-08-12 5:43 GMT+03:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
> 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 ?

No, there is no way.
Now the question is, what type of window is it? If it is a normal
application window you shouldn't try to place it automatically
anywhere, if it is something like a desktop panel we can work toward a
protocol for it.

--
Giulio


>
>
> Thanks and Best Regards
> Steve Zhou
>
>
> -----Original Message-----
> From: Pekka Paalanen [mailto:***@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" <***@gmail.com> wrote:
>
>> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo
>> <***@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.

[Steve (YiLiang) Zhou]

It's a normal application window ,:(

Thanks and Best Regards
Steve Zhou


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

2014-08-12 5:43 GMT+03:00 Steve (YiLiang) Zhou <***@telecomsys.com>:
> 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 ?

No, there is no way.
Now the question is, what type of window is it? If it is a normal application window you shouldn't try to place it automatically anywhere, if it is something like a desktop panel we can work toward a protocol for it.

--
Giulio


>
>
> Thanks and Best Regards
> Steve Zhou
>
>
> -----Original Message-----
> From: Pekka Paalanen [mailto:***@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" <***@gmail.com> wrote:
>
>> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo
>> <***@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.

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 at

[Thiago Macieira]

On Tuesday 12 August 2014 17:40:11 Steve Zhou wrote:
> It's a normal application window ,:(

Then just let the compositor position it. It should be good enough.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Rutledge Shawn]

On 12 Aug 2014, at 6:29 PM, Thiago Macieira wrote:

> On Tuesday 12 August 2014 17:40:11 Steve Zhou wrote:
>> It's a normal application window ,:(
>
> Then just let the compositor position it. It should be good enough.

I guess we have to document which Qt APIs don't and can't work on Wayland then, with the exception that we could add a protocol for the Qt compositor only.

[Giulio Camuffo]

2014-08-13 8:58 GMT+03:00 Rutledge Shawn <***@digia.com>:
>
> On 12 Aug 2014, at 6:29 PM, Thiago Macieira wrote:
>
>> On Tuesday 12 August 2014 17:40:11 Steve Zhou wrote:
>>> It's a normal application window ,:(
>>
>> Then just let the compositor position it. It should be good enough.
>
> I guess we have to document which Qt APIs don't and can't work on Wayland then, with the exception that we could add a protocol for the Qt compositor only.

Technically we could, but we shouldn't, so I wouldn't mention it in the docs.

>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

[Thiago Macieira]

On Wednesday 13 August 2014 10:15:28 Giulio Camuffo wrote:
> 2014-08-13 8:58 GMT+03:00 Rutledge Shawn <***@digia.com>:
> > On 12 Aug 2014, at 6:29 PM, Thiago Macieira wrote:
> >> On Tuesday 12 August 2014 17:40:11 Steve Zhou wrote:
> >>> It's a normal application window ,:(
> >>
> >> Then just let the compositor position it. It should be good enough.
> >
> > I guess we have to document which Qt APIs don't and can't work on Wayland
> > then, with the exception that we could add a protocol for the Qt
> > compositor only.
> Technically we could, but we shouldn't, so I wouldn't mention it in the
> docs.

setGeometry and move, x, y, position, etc. should be documented that they may
not work on some platforms and people should not assume anything about
anything outside of the window. People have to write applications assuming
that the window is already positioned correctly.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Giulio Camuffo]

2014-08-13 18:07 GMT+03:00 Thiago Macieira <***@intel.com>:
> On Wednesday 13 August 2014 10:15:28 Giulio Camuffo wrote:
>> 2014-08-13 8:58 GMT+03:00 Rutledge Shawn <***@digia.com>:
>> > On 12 Aug 2014, at 6:29 PM, Thiago Macieira wrote:
>> >> On Tuesday 12 August 2014 17:40:11 Steve Zhou wrote:
>> >>> It's a normal application window ,:(
>> >>
>> >> Then just let the compositor position it. It should be good enough.
>> >
>> > I guess we have to document which Qt APIs don't and can't work on Wayland
>> > then, with the exception that we could add a protocol for the Qt
>> > compositor only.
>> Technically we could, but we shouldn't, so I wouldn't mention it in the
>> docs.
>
> setGeometry and move, x, y, position, etc. should be documented that they may
> not work on some platforms and people should not assume anything about
> anything outside of the window. People have to write applications assuming
> that the window is already positioned correctly.

Sorry, i wasn't clear. I meant we shouldn't mention the possibility of
a custom protocol, not that setting the window position may not work.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

[Thiago Macieira]

On Wednesday 13 August 2014 18:51:35 Giulio Camuffo wrote:
> Sorry, i wasn't clear. I meant we shouldn't mention the possibility of
> a custom protocol, not that setting the window position may not work.

We shouldn't mention a custom protocol. That's something that only someone
who's already writing a Wayland compositor would be interested in, so this
possibility should be mentioned only in that context.

The QWindow and top-level QWidget documentation should be modified to indicate
that an application may not have access to global positioning or anything
outside its windows (no screen captures, for example). That may also apply to
APIs for grabbing mouse and keyboard.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Jasper St. Pierre]

To be more clear, "interactive moving" being a separate protocol is
actually how it works under X11 too. To begin interactively moving the
window, clients send a _NET_WM_MOVERESIZE ClientMessage [0] to the window
manager which handles moving for it. We adapted the same protocol for
xdg_surface in Wayland.

[0]
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140146176808576


On Mon, Aug 11, 2014 at 6:57 AM, Giulio Camuffo <***@gmail.com>
wrote:

> 2014-08-11 13:29 GMT+03:00 Rutledge Shawn <***@digia.com>:
> >
> > On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote:
> >
> >> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn <***@digia.com>:
> >>>
> >>> On 11 Aug 2014, at 9:10 AM, Pier Luigi wrote:
> >>> (top-posting fixed)
> >>>> 2014-08-11 8:13 GMT+02:00 Steve (YiLiang) Zhou <***@telecomsys.com
> >:
> >>>>> Dear all,
> >>>>>
> >>>>> My app has a mainwindow and a QDialog which is a child of
> mainwindow. And I
> >>>>> want to set the app to the position 0,0.
> >>>>>
> >>>>> I use both setGeometry and move to 0,0. No luck , both failed. The
> window’s
> >>>>> position is unfixed and may appear to anywhere on the screen.
> >>>
> >>> I was wondering about that too. I understand that it's generally good
> policy to leave positioning of generic windows up to the window manager,
> but sometimes you want to write a dock or taskbar which anchors itself to
> screen edges, and can animate in and out of view; or a splash screen which
> is centered on one screen. What is the right way to do that on Wayland?
> >>
> >> The right way is to have a protocol designed for that. A taskbar
> >> should use some taskbar_protocol with a request like
> >> put_on_edge(edge), and the compositor will then move the surface on
> >> the edge and do slide in/out or whatever effect it wants to.
> >
> > I understand the advantage of taking a higher-level approach. But then
> someone thinks of something for which the scenario-specific protocol
> doesn't suffice. If windows could move themselves, it might be more
> flexible. It may be too low-level, but it's hard to think of any other
> protocol that is universal enough, which I suppose is why it's not
> standardized.
>
> 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?
>
> >
> > What about when a window provides its own "skinned" window decorations:
> there will probably be some area in which you can drag to move the window,
> as you normally can on the titlebar. Is there another protocol for that?
> How would that be different from a generic protocol which windows could
> use to position themselves?
>
> wl_shell_surface/xdg_surface have a "move" request. The clients call
> that and then the compositor actually does the moving.
> _______________________________________________
> wayland-devel mailing list
> wayland-***@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



--
Jasper