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

[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 <giuliocamuffo at gmail.com>
wrote:

> 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.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140811/b62c94a1/attachment.html>