[Interest] qt5 window setGeometry and move not work in wayland platform
Jasper St. Pierre
jstpierre at mecheye.net
Mon Aug 11 14:56:31 CEST 2014
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  to the window
manager which handles moving for it. We adapted the same protocol for
xdg_surface in Wayland.
On Mon, Aug 11, 2014 at 6:57 AM, Giulio Camuffo <giuliocamuffo at gmail.com>
> 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
> >>>>> 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
> 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-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest