Re: [Interest] qt5 window setGeometry and move not work in wayland platform
On 11 Aug 2014, at 12:57 PM, Giulio Camuffo wrote: > 2014-08-11 13:29 GMT+03:00 Rutledge Shawn : >> >> On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote: >> >>> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn : 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 : >> 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? On X11 (and other window systems) all outputs are mapped into the "virtual desktop" space, side-by-side or overlapping or whatever, so that there is a unified coordinate system. On Wayland there is not this assumption? > And what is the > position of a window rotated 45 degrees? Something could be made up; perhaps the position should always be the centroid instead of the upper-left? (although in other use cases that would be less convenient) Rotation doesn't make sense without a center of rotation either. >> 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. So interactive moving only, but nothing to ask programmatically for a window to be moved by some delta. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote: > 2014-08-11 12:20 GMT+03:00 Rutledge Shawn : >> >> 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 : 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. 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? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
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 : >> 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? > Clients don't get to set window position with Wayland. > You should write a Wayland protocol for that but you need a compositor > that speaks that protocol. Has it not yet been done in existing compositors such as the Qt one or in Weston? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [Interest] qt5 window setGeometry and move not work in wayland platform
It's a normal application window ,:( Thanks and Best Regards Steve Zhou -Original Message- From: Giulio Camuffo [mailto:giuliocamu...@gmail.com] Sent: Tuesday, August 12, 2014 2:57 PM To: Steve (YiLiang) Zhou Cc: Pekka Paalanen; Nils Chr. Brause; Rutledge Shawn; Pier Luigi; Qt Project; wayland Subject: Re: [Interest] qt5 window setGeometry and move not work in wayland platform 2014-08-12 5:43 GMT+03:00 Steve (YiLiang) Zhou : > Thanks all you guys, > So when it come to my issue, there is no way to adjust the position of > my app which is developed with qt4 and upgraded to qt5 now ,right? > Or can I create a wayland compositor and attach it to my qt window ? No, there is no way. Now the question is, what type of window is it? If it is a normal application window you shouldn't try to place it automatically anywhere, if it is something like a desktop panel we can work toward a protocol for it. -- Giulio > > > Thanks and Best Regards > Steve Zhou > > > -Original Message- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Tuesday, August 12, 2014 1:33 AM > To: Nils Chr. Brause > Cc: Giulio Camuffo; Rutledge Shawn; Steve (YiLiang) Zhou; Pier Luigi; > Qt Project; wayland > Subject: Re: [Interest] qt5 window setGeometry and move not work in > wayland platform > > On Mon, 11 Aug 2014 18:49:50 +0200 > "Nils Chr. Brause" wrote: > >> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo >> >> wrote: >> >> > 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? >> > >> >> Since the question about absolute positioning of windows comes up >> every now and then (and probably will continue to do so for the next >> few years), I thought about a possible way to fix this. >> >> We could create a new interface, that puts an unrotated rectangle >> around a window (which could be transformed in whatever way), that is >> just big enough to fit in the whole window. The upper left corner of >> this rectangle could then be defined as its "position", which could >> be > >> read and set by the user. The size of this rectangle could also be of >> interest of the user, but of course not be set. >> >> Since a window could be on multiple outputs, there would be the need >> for one instance of this interface for every output and every window. >> These could maybe be created and destroyed with events (whenever a >> window appears or disappears on an output). > > Just... no. > > It is a very deliberate design choice to not expose window position. > > Your idea for a bounding box might seem like it could work at first, > but what can an app actually do with it? The app won't have any idea > of how the actual window is really mapped to an output. So far we are > using rectangular outputs, but that does not need to be the case either. > > Window appearance is not limited to just one per output, in fact it > has nothing to do with outputs at all. A window can appear any number > of times anywhere, and with any transformation, if the compositor so > decides. Any of these views may or may not allow user interaction, e.g. > pointer input. > > You would have a lot of work communicating all that to the clients, > even if you used the bounding box approach, and it would be full of > races or round-trips, likely both. > > Yet another reason to not implement a coordinate based window > positioning driven by clients is that clients do not know what else is > on screen, what shape is the screen, etc. > > Just say no to all attempts for such generic positioning, and look at > the actual use case behind it on *why* would this particular case want > to do something like this, what is the real meaning behind it, and > think how the compositor can do the job much better when it knows what > the intention is. > > > Thanks, > pq > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. CONFIDENTIALITY NOTICE: The information contained in this message may be
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
2014-08-12 5:43 GMT+03:00 Steve (YiLiang) Zhou : > Thanks all you guys, > So when it come to my issue, there is no way to adjust the position of > my app which is developed with qt4 and upgraded to qt5 now ,right? > Or can I create a wayland compositor and attach it to my qt window ? No, there is no way. Now the question is, what type of window is it? If it is a normal application window you shouldn't try to place it automatically anywhere, if it is something like a desktop panel we can work toward a protocol for it. -- Giulio > > > Thanks and Best Regards > Steve Zhou > > > -Original Message- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Tuesday, August 12, 2014 1:33 AM > To: Nils Chr. Brause > Cc: Giulio Camuffo; Rutledge Shawn; Steve (YiLiang) Zhou; Pier Luigi; Qt > Project; wayland > Subject: Re: [Interest] qt5 window setGeometry and move not work in > wayland platform > > On Mon, 11 Aug 2014 18:49:50 +0200 > "Nils Chr. Brause" wrote: > >> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo >> >> wrote: >> >> > 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? >> > >> >> Since the question about absolute positioning of windows comes up >> every now and then (and probably will continue to do so for the next >> few years), I thought about a possible way to fix this. >> >> We could create a new interface, that puts an unrotated rectangle >> around a window (which could be transformed in whatever way), that is >> just big enough to fit in the whole window. The upper left corner of >> this rectangle could then be defined as its "position", which could be > >> read and set by the user. The size of this rectangle could also be of >> interest of the user, but of course not be set. >> >> Since a window could be on multiple outputs, there would be the need >> for one instance of this interface for every output and every window. >> These could maybe be created and destroyed with events (whenever a >> window appears or disappears on an output). > > Just... no. > > It is a very deliberate design choice to not expose window position. > > Your idea for a bounding box might seem like it could work at first, but > what can an app actually do with it? The app won't have any idea of how > the actual window is really mapped to an output. So far we are using > rectangular outputs, but that does not need to be the case either. > > Window appearance is not limited to just one per output, in fact it has > nothing to do with outputs at all. A window can appear any number of > times anywhere, and with any transformation, if the compositor so > decides. Any of these views may or may not allow user interaction, e.g. > pointer input. > > You would have a lot of work communicating all that to the clients, even > if you used the bounding box approach, and it would be full of races or > round-trips, likely both. > > Yet another reason to not implement a coordinate based window > positioning driven by clients is that clients do not know what else is > on screen, what shape is the screen, etc. > > Just say no to all attempts for such generic positioning, and look at > the actual use case behind it on *why* would this particular case want > to do something like this, what is the real meaning behind it, and think > how the compositor can do the job much better when it knows what the > intention is. > > > Thanks, > pq > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [Interest] qt5 window setGeometry and move not work in wayland platform
Thanks all you guys, So when it come to my issue, there is no way to adjust the position of my app which is developed with qt4 and upgraded to qt5 now ,right? Or can I create a wayland compositor and attach it to my qt window ? Thanks and Best Regards Steve Zhou -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Tuesday, August 12, 2014 1:33 AM To: Nils Chr. Brause Cc: Giulio Camuffo; Rutledge Shawn; Steve (YiLiang) Zhou; Pier Luigi; Qt Project; wayland Subject: Re: [Interest] qt5 window setGeometry and move not work in wayland platform On Mon, 11 Aug 2014 18:49:50 +0200 "Nils Chr. Brause" wrote: > On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo > > wrote: > > > 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? > > > > Since the question about absolute positioning of windows comes up > every now and then (and probably will continue to do so for the next > few years), I thought about a possible way to fix this. > > We could create a new interface, that puts an unrotated rectangle > around a window (which could be transformed in whatever way), that is > just big enough to fit in the whole window. The upper left corner of > this rectangle could then be defined as its "position", which could be > read and set by the user. The size of this rectangle could also be of > interest of the user, but of course not be set. > > Since a window could be on multiple outputs, there would be the need > for one instance of this interface for every output and every window. > These could maybe be created and destroyed with events (whenever a > window appears or disappears on an output). Just... no. It is a very deliberate design choice to not expose window position. Your idea for a bounding box might seem like it could work at first, but what can an app actually do with it? The app won't have any idea of how the actual window is really mapped to an output. So far we are using rectangular outputs, but that does not need to be the case either. Window appearance is not limited to just one per output, in fact it has nothing to do with outputs at all. A window can appear any number of times anywhere, and with any transformation, if the compositor so decides. Any of these views may or may not allow user interaction, e.g. pointer input. You would have a lot of work communicating all that to the clients, even if you used the bounding box approach, and it would be full of races or round-trips, likely both. Yet another reason to not implement a coordinate based window positioning driven by clients is that clients do not know what else is on screen, what shape is the screen, etc. Just say no to all attempts for such generic positioning, and look at the actual use case behind it on *why* would this particular case want to do something like this, what is the real meaning behind it, and think how the compositor can do the job much better when it knows what the intention is. Thanks, pq CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
On Mon, 11 Aug 2014 18:05:42 -0400 "Jasper St. Pierre" said: > Rotated windows are not the only reason, but they do contribute. The > ability to do an arbitrary transformation on the window is a very useful > feature, for e.g. HiDPI support, and we'd like to expose as little data to > the client as possible so we can enable better use cases. > > The client cannot get or set any transformations on its windows. And it > will never be able to, as long as Kristian, Pekka, Jason, and I are writing > the protocols and the code. totally agree with you on this. there is a danger though. other wl compositors may add it as an extension of their own and then one toolkit breaks rank and uses/needs it and before you know it - all toolkits do this and you have a problem on our hands. the best is education - for developers and toolkit devs. why manual absolute positioning is bad. (your hidpi example is a good one- auto scale "lo dpi" apps up to 2x2 size or whatever). > On Mon, Aug 11, 2014 at 5:59 PM, Bill Spitzak wrote: > > > I don't think rotated windows are the reason they are not supporting > > window position. > > > > Also the corner of the bounding box is a really awful control. Best to > > just use on of the corners, or the center. Assume the client can either get > > or set the rotation so it knows the actual bounding box. > > > > > > On 08/11/2014 09:49 AM, Nils Chr. Brause wrote: > > > >> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo > >> mailto:giuliocamu...@gmail.com>> wrote: > >> > >> 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? > >> > >> > >> Since the question about absolute positioning of windows comes up every > >> now and then (and probably will continue to do so for the next few > >> years), I thought about a possible way to fix this. > >> > >> We could create a new interface, that puts an unrotated rectangle around > >> a window (which could be transformed in whatever way), that is just big > >> enough to fit in the whole window. The upper left corner of this > >> rectangle could then be defined as its "position", which could be read > >> and set by the user. The size of this rectangle could also be of > >> interest of the user, but of course not be set. > >> > >> Since a window could be on multiple outputs, there would be the need for > >> one instance of this interface for every output and every window. These > >> could maybe be created and destroyed with events (whenever a window > >> appears or disappears on an output). > >> > >> This is not 100% thought through, but maybe a starting point. > >> > >> > >> > >> ___ > >> wayland-devel mailing list > >> wayland-devel@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > >> > >> ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > > -- > Jasper -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
Rotated windows are not the only reason, but they do contribute. The ability to do an arbitrary transformation on the window is a very useful feature, for e.g. HiDPI support, and we'd like to expose as little data to the client as possible so we can enable better use cases. The client cannot get or set any transformations on its windows. And it will never be able to, as long as Kristian, Pekka, Jason, and I are writing the protocols and the code. On Mon, Aug 11, 2014 at 5:59 PM, Bill Spitzak wrote: > I don't think rotated windows are the reason they are not supporting > window position. > > Also the corner of the bounding box is a really awful control. Best to > just use on of the corners, or the center. Assume the client can either get > or set the rotation so it knows the actual bounding box. > > > On 08/11/2014 09:49 AM, Nils Chr. Brause wrote: > >> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo >> mailto:giuliocamu...@gmail.com>> wrote: >> >> 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? >> >> >> Since the question about absolute positioning of windows comes up every >> now and then (and probably will continue to do so for the next few >> years), I thought about a possible way to fix this. >> >> We could create a new interface, that puts an unrotated rectangle around >> a window (which could be transformed in whatever way), that is just big >> enough to fit in the whole window. The upper left corner of this >> rectangle could then be defined as its "position", which could be read >> and set by the user. The size of this rectangle could also be of >> interest of the user, but of course not be set. >> >> Since a window could be on multiple outputs, there would be the need for >> one instance of this interface for every output and every window. These >> could maybe be created and destroyed with events (whenever a window >> appears or disappears on an output). >> >> This is not 100% thought through, but maybe a starting point. >> >> >> >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >> ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
I don't think rotated windows are the reason they are not supporting window position. Also the corner of the bounding box is a really awful control. Best to just use on of the corners, or the center. Assume the client can either get or set the rotation so it knows the actual bounding box. On 08/11/2014 09:49 AM, Nils Chr. Brause wrote: On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo mailto:giuliocamu...@gmail.com>> wrote: 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? Since the question about absolute positioning of windows comes up every now and then (and probably will continue to do so for the next few years), I thought about a possible way to fix this. We could create a new interface, that puts an unrotated rectangle around a window (which could be transformed in whatever way), that is just big enough to fit in the whole window. The upper left corner of this rectangle could then be defined as its "position", which could be read and set by the user. The size of this rectangle could also be of interest of the user, but of course not be set. Since a window could be on multiple outputs, there would be the need for one instance of this interface for every output and every window. These could maybe be created and destroyed with events (whenever a window appears or disappears on an output). This is not 100% thought through, but maybe a starting point. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
On Mon, 11 Aug 2014 18:49:50 +0200 "Nils Chr. Brause" wrote: > On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo > wrote: > > > 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? > > > > Since the question about absolute positioning of windows comes up every now > and then (and probably will continue to do so for the next few years), I > thought about a possible way to fix this. > > We could create a new interface, that puts an unrotated rectangle around a > window (which could be transformed in whatever way), that is just big > enough to fit in the whole window. The upper left corner of this rectangle > could then be defined as its "position", which could be read and set by the > user. The size of this rectangle could also be of interest of the user, but > of course not be set. > > Since a window could be on multiple outputs, there would be the need for > one instance of this interface for every output and every window. These > could maybe be created and destroyed with events (whenever a window appears > or disappears on an output). Just... no. It is a very deliberate design choice to not expose window position. Your idea for a bounding box might seem like it could work at first, but what can an app actually do with it? The app won't have any idea of how the actual window is really mapped to an output. So far we are using rectangular outputs, but that does not need to be the case either. Window appearance is not limited to just one per output, in fact it has nothing to do with outputs at all. A window can appear any number of times anywhere, and with any transformation, if the compositor so decides. Any of these views may or may not allow user interaction, e.g. pointer input. You would have a lot of work communicating all that to the clients, even if you used the bounding box approach, and it would be full of races or round-trips, likely both. Yet another reason to not implement a coordinate based window positioning driven by clients is that clients do not know what else is on screen, what shape is the screen, etc. Just say no to all attempts for such generic positioning, and look at the actual use case behind it on *why* would this particular case want to do something like this, what is the real meaning behind it, and think how the compositor can do the job much better when it knows what the intention is. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo wrote: > 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? > Since the question about absolute positioning of windows comes up every now and then (and probably will continue to do so for the next few years), I thought about a possible way to fix this. We could create a new interface, that puts an unrotated rectangle around a window (which could be transformed in whatever way), that is just big enough to fit in the whole window. The upper left corner of this rectangle could then be defined as its "position", which could be read and set by the user. The size of this rectangle could also be of interest of the user, but of course not be set. Since a window could be on multiple outputs, there would be the need for one instance of this interface for every output and every window. These could maybe be created and destroyed with events (whenever a window appears or disappears on an output). This is not 100% thought through, but maybe a starting point. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
2014-08-11 16:12 GMT+03:00 Rutledge Shawn : > > On 11 Aug 2014, at 12:57 PM, Giulio Camuffo wrote: > >> 2014-08-11 13:29 GMT+03:00 Rutledge Shawn : >>> >>> On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote: >>> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn : > > 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 : >>> 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? > > On X11 (and other window systems) all outputs are mapped into the "virtual > desktop" space, side-by-side or overlapping or whatever, so that there is a > unified coordinate system. On Wayland there is not this assumption? I'm not sure I follow. How does that fix the problem of the same window being shown at the same time at 10x10 of an output and at 0x0 of another one? > >> And what is the >> position of a window rotated 45 degrees? > > Something could be made up; perhaps the position should always be the > centroid instead of the upper-left? (although in other use cases that would > be less convenient) Rotation doesn't make sense without a center of rotation > either. > >>> 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. > > So interactive moving only, but nothing to ask programmatically for a window > to be moved by some delta. Actually, both. Clients can ask the compositor to move a surface by a dx,dy when attaching a buffer. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
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 wrote: > 2014-08-11 13:29 GMT+03:00 Rutledge Shawn : > > > > On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote: > > > >> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn : > >>> > >>> 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 >: > > 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
2014-08-11 13:29 GMT+03:00 Rutledge Shawn : > > On 11 Aug 2014, at 11:34 AM, Giulio Camuffo wrote: > >> 2014-08-11 12:20 GMT+03:00 Rutledge Shawn : >>> >>> 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 : > 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Interest] qt5 window setGeometry and move not work in wayland platform
2014-08-11 12:20 GMT+03:00 Rutledge Shawn : > > 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 : >>> 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. > >> Clients don't get to set window position with Wayland. >> You should write a Wayland protocol for that but you need a compositor >> that speaks that protocol. > > Has it not yet been done in existing compositors such as the Qt one or in > Weston? Not in QtCompositor. Weston has a private protocol to set some surface as a panel, but it is private and weston-specific. -- Giulio > > ___ > Interest mailing list > inter...@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
