Issue with initial window position

[Pekka Paalanen]

On Thu, 14 Jun 2018 12:09:03 +0000
PrasanthKumar P.A. <PrasanthKumar.PA at nestgroup.net> wrote:

> Hi,
> Thank you for your quick response.
> These  are our concerns.
> Our application is a HMI that is to be deployed on IMX8 board.
> By design we need to place some  QT Qml windows on specified x y
> coordinates on the screen  .How can we achieve this ?

Usually you run a compositor that knows to place your special windows
correctly, perhaps with some aid from a custom protocol extension that
tells the compositor what kind of window it is.

If a client knows at what coordinates its window should go, then the
compositor would know that as well if it just knows the detailed type
of each window. The compositor always knows at least as much as any
client, because on Wayland clients are by default isolated from each
other: no client knows what else is on the screen. Only an entity that
knows what else is on screen will be able to position windows
correctly. The compositor necessarily is one such an entity.

Desktop systems have no closed design and there one cannot know
beforehand what else might be on the screen, and for containment and
privacy reasons there is no protocol for an arbitrary client to even
find out.

If the compositor is placing windows freely in a VR environment, then a
client trying to position its window by x,y coordinates is meaningless.

The design principle is to give the window manager enough semantical
information to manage windows correctly, instead of letting clients
fight with the window manager.

> Also I am interested on (If your target environment is not a desktop,
> then the design could be different). Can you please comment on this.

The family of IVI protocol extensions for Wayland is an example of a
non-desktop design.

Systems with essentially closed design the components on screen can be
defined before-hand, and therefore the system designer can choose their
positions. How those positions are then realized becomes an
implementation detail which is often solved by some protocols, (custom)
Wayland extensions or otherwise.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180614/52f0d090/attachment.sig>