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

[Giulio Camuffo]

2014-08-11 13:29 GMT+03:00 Rutledge Shawn <Shawn.Rutledge at digia.com>:
>
> On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote:
>
>> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn <Shawn.Rutledge at 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 <szhou at 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.