Discussion:
random window position with desktop shell
Nancy Zou
2015-09-25 07:03:41 UTC
Permalink
Dear All:

Can I ask why desktop shell create a new window with random initial position? Can I modify it to fixed position in weston_view_set_initial_position? How can the Weston client get the window initial position?

Thank you.
Best Regards
Nancy
Pekka Paalanen
2015-09-25 08:37:45 UTC
Permalink
Hi Nancy

On Fri, 25 Sep 2015 07:03:41 +0000
Post by Nancy Zou
Can I ask why desktop shell create a new window with random initial
position?
So that people who assume anything about the window position would get
caught. Non-deterministic positioning logic is good for that.

A lesser reason is that we have not bothered with implementing
any nice initial window positioning logic, and personally I think we
don't even want that in Weston's desktop shell.
Post by Nancy Zou
Can I modify it to fixed position in
weston_view_set_initial_position?
Please do not. Clients should not assume anything about the initial
top-level window position when not maximized or fullscreened.
Post by Nancy Zou
How can the Weston client get the
window initial position?
They cannot. There is no public coordinate space to even describe it
with. See e.g.


It is a design decision in Wayland/desktop to not expose absolute
window positions to clients at all. This means that you simply cannot
know where a top-level window is precisely, you can only know which
outputs it overlaps with.

Windows that are not top-level can often be placed relative to another
wl_surface. This is the only form of precise positioning supported on
desktops.


Thanks,
pq
Bill Spitzak
2015-09-25 17:46:21 UTC
Permalink
This post might be inappropriate. Click to display it.
Daniel Stone
2015-09-28 09:13:09 UTC
Permalink
Post by Bill Spitzak
Post by Pekka Paalanen
It is a design decision in Wayland/desktop to not expose absolute
window positions to clients at all. This means that you simply cannot
know where a top-level window is precisely, you can only know which
outputs it overlaps with.
This is an interesting experiement but I believe it is doomed in the long
run. I would try it
We have, ever since Wayland's creation. It works.
Post by Bill Spitzak
but I think the end result is that every single desktop
environment will add this as an "extension"
None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
digital signage, not video walls, not set-top boxes, not smart TVs,
not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.
Post by Bill Spitzak
because so much software will not work without it.
It does.
Post by Bill Spitzak
You have to realize that X and Windows and OSX all use
2 numbers to describe the location of a window
Yeah, I'm well aware of how the X input stack works.
Post by Bill Spitzak
and thus getting software to
stop assuming that is probably a Sisyphean task.
It hasn't been.
Post by Bill Spitzak
Post by Pekka Paalanen
Windows that are not top-level can often be placed relative to another
wl_surface. This is the only form of precise positioning supported on
desktops.
This is correct and could make it work in the vast majority of cases, but
supporting portable programs is going to be difficult and hacky. Qt code,
for instance, calculate QPoint objects (which contain 2 numbers) and assume
the result fully defines where a menu will pop up. Now they usually
calculate these by asking for the position of existing widgets and adding
offsets, so if the returned coordinates are in a space such that the future
parent is at 0,0 then this will work acceptably. But I fully expect Qt to
first look for the window-position extension and use that if possible, with
this hack as a rarely-used fallback.
Your expectations are wrong. Look at how Qt has worked just fine (and
shipped in many environments) without it for years.

This is another dead end of a thread. It's been this way for years
because of very valid reasons, it works (despite you being convinced
that it could never work) fine, and it's not changing.

If you'd like to productively contribute to this, perhaps you could
pick up the surface position negotiation protocol, which would allow
clients to guarantee that menus would not be positioned off-screen.

Cheers,
Daniel
Jasper St. Pierre
2015-09-28 15:54:52 UTC
Permalink
To be honest, the more I think about it, the more likely I am to just
want to add back in a global coordinate system. There's too many
problems that GNOME is having by omitting it. For starters, menu and
tooltip positioning that works correctly. Saving and restarting window
positions is something that I've desperately missed ever since I
started using Linux on my multimonitor desktop rig again.

I don't see many of the advantages of omitting a global coordinate
system anymore, and I don't see many downsides, and a lot of issues
we're having seem to be predicated by this. I want Wayland to succeed,
and that might mean that we go back to a simpler idea.
Post by Daniel Stone
Post by Bill Spitzak
Post by Pekka Paalanen
It is a design decision in Wayland/desktop to not expose absolute
window positions to clients at all. This means that you simply cannot
know where a top-level window is precisely, you can only know which
outputs it overlaps with.
This is an interesting experiement but I believe it is doomed in the long
run. I would try it
We have, ever since Wayland's creation. It works.
Post by Bill Spitzak
but I think the end result is that every single desktop
environment will add this as an "extension"
None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
digital signage, not video walls, not set-top boxes, not smart TVs,
not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.
Post by Bill Spitzak
because so much software will not work without it.
It does.
Post by Bill Spitzak
You have to realize that X and Windows and OSX all use
2 numbers to describe the location of a window
Yeah, I'm well aware of how the X input stack works.
Post by Bill Spitzak
and thus getting software to
stop assuming that is probably a Sisyphean task.
It hasn't been.
Post by Bill Spitzak
Post by Pekka Paalanen
Windows that are not top-level can often be placed relative to another
wl_surface. This is the only form of precise positioning supported on
desktops.
This is correct and could make it work in the vast majority of cases, but
supporting portable programs is going to be difficult and hacky. Qt code,
for instance, calculate QPoint objects (which contain 2 numbers) and assume
the result fully defines where a menu will pop up. Now they usually
calculate these by asking for the position of existing widgets and adding
offsets, so if the returned coordinates are in a space such that the future
parent is at 0,0 then this will work acceptably. But I fully expect Qt to
first look for the window-position extension and use that if possible, with
this hack as a rarely-used fallback.
Your expectations are wrong. Look at how Qt has worked just fine (and
shipped in many environments) without it for years.
This is another dead end of a thread. It's been this way for years
because of very valid reasons, it works (despite you being convinced
that it could never work) fine, and it's not changing.
If you'd like to productively contribute to this, perhaps you could
pick up the surface position negotiation protocol, which would allow
clients to guarantee that menus would not be positioned off-screen.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
Giulio Camuffo
2015-09-28 18:26:43 UTC
Permalink
Post by Jasper St. Pierre
To be honest, the more I think about it, the more likely I am to just
want to add back in a global coordinate system. There's too many
problems that GNOME is having by omitting it. For starters, menu and
tooltip positioning that works correctly. Saving and restarting window
positions is something that I've desperately missed ever since I
started using Linux on my multimonitor desktop rig again.
I don't see many of the advantages of omitting a global coordinate
system anymore, and I don't see many downsides, and a lot of issues
we're having seem to be predicated by this. I want Wayland to succeed,
and that might mean that we go back to a simpler idea.
In orbital i use multiple views for any surface and put them in
separate places. If a client asked for a surface position i wouldn't
know what to tell it, and indeed xwayland apps don't really work
correctly all the times. Instead of going back it's better to address
the remaining problems.
In my experience i'm not noticing any problem, except popup menus
occasionally showing up in the wrong place in qt apps, a bug i have
yet to debug but which i think will not be unfixable. (but i don't use
gtk apps, so i don't know about those)
Saving window positions does indeed need to be addressed, however i
would not trade that off with the flexibility not having surface
positions gives me.

--
Giulio
Post by Jasper St. Pierre
Post by Daniel Stone
Post by Bill Spitzak
Post by Pekka Paalanen
It is a design decision in Wayland/desktop to not expose absolute
window positions to clients at all. This means that you simply cannot
know where a top-level window is precisely, you can only know which
outputs it overlaps with.
This is an interesting experiement but I believe it is doomed in the long
run. I would try it
We have, ever since Wayland's creation. It works.
Post by Bill Spitzak
but I think the end result is that every single desktop
environment will add this as an "extension"
None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
digital signage, not video walls, not set-top boxes, not smart TVs,
not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.
Post by Bill Spitzak
because so much software will not work without it.
It does.
Post by Bill Spitzak
You have to realize that X and Windows and OSX all use
2 numbers to describe the location of a window
Yeah, I'm well aware of how the X input stack works.
Post by Bill Spitzak
and thus getting software to
stop assuming that is probably a Sisyphean task.
It hasn't been.
Post by Bill Spitzak
Post by Pekka Paalanen
Windows that are not top-level can often be placed relative to another
wl_surface. This is the only form of precise positioning supported on
desktops.
This is correct and could make it work in the vast majority of cases, but
supporting portable programs is going to be difficult and hacky. Qt code,
for instance, calculate QPoint objects (which contain 2 numbers) and assume
the result fully defines where a menu will pop up. Now they usually
calculate these by asking for the position of existing widgets and adding
offsets, so if the returned coordinates are in a space such that the future
parent is at 0,0 then this will work acceptably. But I fully expect Qt to
first look for the window-position extension and use that if possible, with
this hack as a rarely-used fallback.
Your expectations are wrong. Look at how Qt has worked just fine (and
shipped in many environments) without it for years.
This is another dead end of a thread. It's been this way for years
because of very valid reasons, it works (despite you being convinced
that it could never work) fine, and it's not changing.
If you'd like to productively contribute to this, perhaps you could
pick up the surface position negotiation protocol, which would allow
clients to guarantee that menus would not be positioned off-screen.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Daniel Stone
2015-09-28 18:55:24 UTC
Permalink
Hi,
Post by Jasper St. Pierre
To be honest, the more I think about it, the more likely I am to just
want to add back in a global coordinate system. There's too many
problems that GNOME is having by omitting it. For starters, menu and
tooltip positioning that works correctly.
You don't need a global co-ordinate system for that:
http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html
Post by Jasper St. Pierre
Saving and restarting window
positions is something that I've desperately missed ever since I
started using Linux on my multimonitor desktop rig again.
You don't need a global co-ordinate system for that: the consensus for
save/restore has long been for a cookie-based system, which would
allow the compositor to store position, workspace, and any other
attributes.
Post by Jasper St. Pierre
I don't see many of the advantages of omitting a global coordinate
system anymore, and I don't see many downsides, and a lot of issues
we're having seem to be predicated by this. I want Wayland to succeed,
and that might mean that we go back to a simpler idea.
Those are two problems, both of which are well understood and
relatively easily solved.

Omitting a global co-ordinate space does solve a great deal of
problems, particularly in the input space, and opens up a whole array
of possibilities that X's communication of a flat global co-ordinate
space precluded us from ever pursuing. Rowing back on that because of
two problems which can be better solved elsewhere would be a real
waste, and not something I've seen any appetite for amongst the
others.

Cheers,
Daniel
Post by Jasper St. Pierre
Post by Daniel Stone
Post by Bill Spitzak
Post by Pekka Paalanen
It is a design decision in Wayland/desktop to not expose absolute
window positions to clients at all. This means that you simply cannot
know where a top-level window is precisely, you can only know which
outputs it overlaps with.
This is an interesting experiement but I believe it is doomed in the long
run. I would try it
We have, ever since Wayland's creation. It works.
Post by Bill Spitzak
but I think the end result is that every single desktop
environment will add this as an "extension"
None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
digital signage, not video walls, not set-top boxes, not smart TVs,
not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.
Post by Bill Spitzak
because so much software will not work without it.
It does.
Post by Bill Spitzak
You have to realize that X and Windows and OSX all use
2 numbers to describe the location of a window
Yeah, I'm well aware of how the X input stack works.
Post by Bill Spitzak
and thus getting software to
stop assuming that is probably a Sisyphean task.
It hasn't been.
Post by Bill Spitzak
Post by Pekka Paalanen
Windows that are not top-level can often be placed relative to another
wl_surface. This is the only form of precise positioning supported on
desktops.
This is correct and could make it work in the vast majority of cases, but
supporting portable programs is going to be difficult and hacky. Qt code,
for instance, calculate QPoint objects (which contain 2 numbers) and assume
the result fully defines where a menu will pop up. Now they usually
calculate these by asking for the position of existing widgets and adding
offsets, so if the returned coordinates are in a space such that the future
parent is at 0,0 then this will work acceptably. But I fully expect Qt to
first look for the window-position extension and use that if possible, with
this hack as a rarely-used fallback.
Your expectations are wrong. Look at how Qt has worked just fine (and
shipped in many environments) without it for years.
This is another dead end of a thread. It's been this way for years
because of very valid reasons, it works (despite you being convinced
that it could never work) fine, and it's not changing.
If you'd like to productively contribute to this, perhaps you could
pick up the surface position negotiation protocol, which would allow
clients to guarantee that menus would not be positioned off-screen.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
Benoit Gschwind
2015-09-29 13:05:04 UTC
Permalink
Hello,

Maybe my thought is insignificant, but I would like to share it anyway,
as young window manager developer.

I think all your arguments (both side) are valid. But I will defend the
point of view of Jasper. While technically I agree there is no need of
absolute positioning and many solution are available to solve issues of
no-absolute position. I will submit 3 arguments. The first one is that
current proposed solution of no-absolute position case are not existing,
i.e. only marginal, experimental or not at all implemented, but there is
many running software out there that rely on legacy absolute position.
Jasper (as I understood) propose to add a layer to make the transition
smoother and easier. This doesn't hurt too much, imo.
The second one is that most of main stream software transition follow
this rules, having a transition period (or "mercy" period), I will take
three examples. Within gcc architecture that are not maintained fall in
deprecated state for few release cycle, if no one maintain it during
this "mercy" period, they get removed. The developers have few release
cycles to adapt. GTK use a similar policy by deprecating APIs. And the
last exemple, I still be able to run 32 bits apps on my shiny new
laptop. I think it's no hurt to give the opportunity to the developer to
have a "mercy" period, within they can learn Wayland and adapt their
software.
The third one is that even if you try you best to have a clean protocol,
I'm sure developers will find ways to abuse or exploit your protocol in
a way you never thought. In those case I think the best choice is to
manage those exploits and not trying to _enforce_ you protocol (I do not
cover security with this sentence).

All in all, I think that having a dedicated "compatibility to X11
legacy" extension is useful, this extension can be deprecated and
removed over time, until solutions proposed are effectively implemented.
I also agree that this layer should be smallest as possible. With this
kind of extension, old X11 developers can get used with Wayland
philosophy and learn. If you put a tall fence between old developers and
wayland, you will be in lose-lose case, application developers will hate
you for your unshakable church and you get less people that use your
work. I also want to recall that old software have also a lot of
experiments behind them and this is them that will have the most hard
work: migrating to Wayland. In his side, Wayland is a small peace of
code (and the protocol is even smaller).

Best regards.

--
Blocage

"The most secure network protocol is no-network at all".
Post by Daniel Stone
Hi,
Post by Jasper St. Pierre
To be honest, the more I think about it, the more likely I am to just
want to add back in a global coordinate system. There's too many
problems that GNOME is having by omitting it. For starters, menu and
tooltip positioning that works correctly.
http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html
Post by Jasper St. Pierre
Saving and restarting window
positions is something that I've desperately missed ever since I
started using Linux on my multimonitor desktop rig again.
You don't need a global co-ordinate system for that: the consensus for
save/restore has long been for a cookie-based system, which would
allow the compositor to store position, workspace, and any other
attributes.
Post by Jasper St. Pierre
I don't see many of the advantages of omitting a global coordinate
system anymore, and I don't see many downsides, and a lot of issues
we're having seem to be predicated by this. I want Wayland to succeed,
and that might mean that we go back to a simpler idea.
Those are two problems, both of which are well understood and
relatively easily solved.
Omitting a global co-ordinate space does solve a great deal of
problems, particularly in the input space, and opens up a whole array
of possibilities that X's communication of a flat global co-ordinate
space precluded us from ever pursuing. Rowing back on that because of
two problems which can be better solved elsewhere would be a real
waste, and not something I've seen any appetite for amongst the
others.
Cheers,
Daniel
Post by Jasper St. Pierre
Post by Daniel Stone
Post by Bill Spitzak
Post by Pekka Paalanen
It is a design decision in Wayland/desktop to not expose absolute
window positions to clients at all. This means that you simply cannot
know where a top-level window is precisely, you can only know which
outputs it overlaps with.
This is an interesting experiement but I believe it is doomed in the long
run. I would try it
We have, ever since Wayland's creation. It works.
Post by Bill Spitzak
but I think the end result is that every single desktop
environment will add this as an "extension"
None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
digital signage, not video walls, not set-top boxes, not smart TVs,
not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.
Post by Bill Spitzak
because so much software will not work without it.
It does.
Post by Bill Spitzak
You have to realize that X and Windows and OSX all use
2 numbers to describe the location of a window
Yeah, I'm well aware of how the X input stack works.
Post by Bill Spitzak
and thus getting software to
stop assuming that is probably a Sisyphean task.
It hasn't been.
Post by Bill Spitzak
Post by Pekka Paalanen
Windows that are not top-level can often be placed relative to another
wl_surface. This is the only form of precise positioning supported on
desktops.
This is correct and could make it work in the vast majority of cases, but
supporting portable programs is going to be difficult and hacky. Qt code,
for instance, calculate QPoint objects (which contain 2 numbers) and assume
the result fully defines where a menu will pop up. Now they usually
calculate these by asking for the position of existing widgets and adding
offsets, so if the returned coordinates are in a space such that the future
parent is at 0,0 then this will work acceptably. But I fully expect Qt to
first look for the window-position extension and use that if possible, with
this hack as a rarely-used fallback.
Your expectations are wrong. Look at how Qt has worked just fine (and
shipped in many environments) without it for years.
This is another dead end of a thread. It's been this way for years
because of very valid reasons, it works (despite you being convinced
that it could never work) fine, and it's not changing.
If you'd like to productively contribute to this, perhaps you could
pick up the surface position negotiation protocol, which would allow
clients to guarantee that menus would not be positioned off-screen.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Daniel Stone
2015-09-29 13:55:52 UTC
Permalink
Hi,
Post by Benoit Gschwind
Maybe my thought is insignificant, but I would like to share it anyway,
as young window manager developer.
It's fair enough, and I see what you have to say. All I really have to
say in return is two things:
- if we add global co-ordinates back now, we can never remove them:
people will rely on them, and removing them will break peoples' apps.
As the kernel's regression policy has shown, it's better not to break
things that work already.
- certainly neither of those things have happened yet, but that
doesn't mean they can't ever happen; if we exposed global
co-ordinates, people would just use those and _never_ work on these
sensible replacements, thus removing all incentive to work towards a
better protocol

For those reasons, I'm holding out personally.

(FWIW, the XWayland integration picks one 'master' view of a surface
for positioning purposes, and ensures that XWayland positions its
windows at the same point, to account for X's dependence on a global
co-ordinate system.)

Cheers,
Daniel
Post by Benoit Gschwind
I think all your arguments (both side) are valid. But I will defend the
point of view of Jasper. While technically I agree there is no need of
absolute positioning and many solution are available to solve issues of
no-absolute position. I will submit 3 arguments. The first one is that
current proposed solution of no-absolute position case are not existing,
i.e. only marginal, experimental or not at all implemented, but there is
many running software out there that rely on legacy absolute position.
Jasper (as I understood) propose to add a layer to make the transition
smoother and easier. This doesn't hurt too much, imo.
The second one is that most of main stream software transition follow
this rules, having a transition period (or "mercy" period), I will take
three examples. Within gcc architecture that are not maintained fall in
deprecated state for few release cycle, if no one maintain it during
this "mercy" period, they get removed. The developers have few release
cycles to adapt. GTK use a similar policy by deprecating APIs. And the
last exemple, I still be able to run 32 bits apps on my shiny new
laptop. I think it's no hurt to give the opportunity to the developer to
have a "mercy" period, within they can learn Wayland and adapt their
software.
The third one is that even if you try you best to have a clean protocol,
I'm sure developers will find ways to abuse or exploit your protocol in
a way you never thought. In those case I think the best choice is to
manage those exploits and not trying to _enforce_ you protocol (I do not
cover security with this sentence).
All in all, I think that having a dedicated "compatibility to X11
legacy" extension is useful, this extension can be deprecated and
removed over time, until solutions proposed are effectively implemented.
I also agree that this layer should be smallest as possible. With this
kind of extension, old X11 developers can get used with Wayland
philosophy and learn. If you put a tall fence between old developers and
wayland, you will be in lose-lose case, application developers will hate
you for your unshakable church and you get less people that use your
work. I also want to recall that old software have also a lot of
experiments behind them and this is them that will have the most hard
work: migrating to Wayland. In his side, Wayland is a small peace of
code (and the protocol is even smaller).
Best regards.
--
Blocage
"The most secure network protocol is no-network at all".
Post by Daniel Stone
Hi,
Post by Jasper St. Pierre
To be honest, the more I think about it, the more likely I am to just
want to add back in a global coordinate system. There's too many
problems that GNOME is having by omitting it. For starters, menu and
tooltip positioning that works correctly.
http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html
Post by Jasper St. Pierre
Saving and restarting window
positions is something that I've desperately missed ever since I
started using Linux on my multimonitor desktop rig again.
You don't need a global co-ordinate system for that: the consensus for
save/restore has long been for a cookie-based system, which would
allow the compositor to store position, workspace, and any other
attributes.
Post by Jasper St. Pierre
I don't see many of the advantages of omitting a global coordinate
system anymore, and I don't see many downsides, and a lot of issues
we're having seem to be predicated by this. I want Wayland to succeed,
and that might mean that we go back to a simpler idea.
Those are two problems, both of which are well understood and
relatively easily solved.
Omitting a global co-ordinate space does solve a great deal of
problems, particularly in the input space, and opens up a whole array
of possibilities that X's communication of a flat global co-ordinate
space precluded us from ever pursuing. Rowing back on that because of
two problems which can be better solved elsewhere would be a real
waste, and not something I've seen any appetite for amongst the
others.
Cheers,
Daniel
Post by Jasper St. Pierre
Post by Daniel Stone
Post by Bill Spitzak
Post by Pekka Paalanen
It is a design decision in Wayland/desktop to not expose absolute
window positions to clients at all. This means that you simply cannot
know where a top-level window is precisely, you can only know which
outputs it overlaps with.
This is an interesting experiement but I believe it is doomed in the long
run. I would try it
We have, ever since Wayland's creation. It works.
Post by Bill Spitzak
but I think the end result is that every single desktop
environment will add this as an "extension"
None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
digital signage, not video walls, not set-top boxes, not smart TVs,
not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.
Post by Bill Spitzak
because so much software will not work without it.
It does.
Post by Bill Spitzak
You have to realize that X and Windows and OSX all use
2 numbers to describe the location of a window
Yeah, I'm well aware of how the X input stack works.
Post by Bill Spitzak
and thus getting software to
stop assuming that is probably a Sisyphean task.
It hasn't been.
Post by Bill Spitzak
Post by Pekka Paalanen
Windows that are not top-level can often be placed relative to another
wl_surface. This is the only form of precise positioning supported on
desktops.
This is correct and could make it work in the vast majority of cases, but
supporting portable programs is going to be difficult and hacky. Qt code,
for instance, calculate QPoint objects (which contain 2 numbers) and assume
the result fully defines where a menu will pop up. Now they usually
calculate these by asking for the position of existing widgets and adding
offsets, so if the returned coordinates are in a space such that the future
parent is at 0,0 then this will work acceptably. But I fully expect Qt to
first look for the window-position extension and use that if possible, with
this hack as a rarely-used fallback.
Your expectations are wrong. Look at how Qt has worked just fine (and
shipped in many environments) without it for years.
This is another dead end of a thread. It's been this way for years
because of very valid reasons, it works (despite you being convinced
that it could never work) fine, and it's not changing.
If you'd like to productively contribute to this, perhaps you could
pick up the surface position negotiation protocol, which would allow
clients to guarantee that menus would not be positioned off-screen.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
_______________________________________________
wayland-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Derek Foreman
2015-09-29 14:06:57 UTC
Permalink
This post might be inappropriate. Click to display it.
Loading...