Re: Window positions under wayland
Hi: Is it that more people think that not allowed the window to set their position is better? I think that Wayland is better than X11 In this regard. It is correct to not let the window be set position, But some people will have doubts, because their know that some windows need to set their own position. We should pay attention to these needs and analyze what is the real reason their need for this interface, I don't think most of the window do not care about their positions, such as Chrome or Firefox, and some other commonly used applications, such as terminals, vscode, QtCreator, can not set positions is without any effect on them. In addition, there are some special windows, such as taskbar, message notifications, etc, They need to control the position of the window in screen, and they also need to set the layer of the window, such as the desktop window is always at the bottom, the taskbar window has been at the top. In fact such applications are usually provided by the desktop environment, the Wayland compositor can provide support for them, different desktop environments can fully control all their windows, this is right, they do not need Wayland to provide the interface of setting window positions. In addition to the above two examples, some windows are neither part of the desktop environment and and does need to control the position of the window (I'm using "control" instead of "set" here because I think they just need a way to control the position of the window, rather than having to use something like the X11 way of setting window coordinates). For a example, there have a window, when the user drags it to the edge of the screen and releases the mouse, which will to hidden, display only a small part of the window at the edge of the screen, and when the mouse hover in this part of the exposed area, the window will full display. I have used some applications like this, I'm sorry I couldn't find a GIF picture about it, I hope you understand what kind of feature I described. I think such demand is reasonable, the demand can be implemented in other ways instead of providing the interface of the set window position. In the case I give an example, we can provide it with a allowable window to set its anchor on the screen, such as: void handle_shell_surface_move_finished(wl_surface *s) { QRegion visible_region = get_surface_visible_region_in_current_screen(s); QRect rect = visible_region.boundingRect(); if (rect.y() > 0) { // Hidden the window to the top edge of the screen wl_shell_surface_anchors *screen_anchors = wl_shell_surface_get_screen_anchors(s); wl_shell_surface_anchors *window_anchors = wl_shell_surface_get_anchors(s); // Requires the bottom edge of the window to align with the top edge of the screen, and have 10px margins. You can only see the 10px height content at the bottom of the window on the screen. wl_shell_surface_request_anchors(window_anchors->bottom, screen_anchors->top, 10); } } I think this interface that is not setting absolute coordinates will be more friendly for the application, most similar needs can be solved using this like interface. Do you think so and do you have any other examples to introduce? -- JiDe Zhang -- linuxdeepin. From: wayland-devel on behalf of samuel ammonius Sent: Sunday, August 7, 2022 01:15 To: Igor Korot Cc: Thiago Macieira ; Daniel Stone ; wayland-devel@lists.freedesktop.org Subject: Re: Window positions under wayland No one responded to my last email, so I'll just assume it was because everyone aggeed with it and not because it was so horribly structured that no one understood a thing I was saying :). It would be possible to redesign Wayland following the principles you have described. No-one is doing this, however. If I added this feature through git, would it be accepted? It would just be "void wl_surface_request_position(wl_surface *surface, unsigned int x, unsigned int y);" On Fri, Aug 5, 2022 at 8:14 PM samuel ammonius mailto:sfammon...@gmail.com>> wrote: Sorry, I just read over my last email and realized that I didn't even state what I was trying to say. I meant my last suggestion of letting the compositor handle the resize event. I was just giving some reasons as to why it may be the best solution. On Fri, Aug 5, 2022 at 6:32 PM samuel ammonius mailto:sfammon...@gmail.com>> wrote: I don't understand why we're all asking if it should be up to the compositor or app to set a window's position. The only correct answer is that it should be up to the user, so I don't see what's wrong with my suggestion of a "set window size request" function. Waylands idea of not letting apps set their window position because it thinks it knows better is very similar to what's wrong with commercial operating systems nowadays, and it's probably why many of us left Windows. For example, you could only disable "live s
Re: Window positions under wayland
On 08/08/2022 09:05, JiDe Zhang wrote: Hi: Is it that more people think that not allowed the window to set their position is better? I think that Wayland is better than X11 In this regard. It is correct to not let the window be set position, But some people will have doubts, because their know that some windows need to set their own position. We should pay attention to these needs and analyze what is the real reason their need for this interface, It is entirely understandable for the designers of applications and application toolkits to be surprised they don't have the control they have in other windowing systems (X11, Windows, whatever). For decades they've been used to deciding where their windows go. Trusting the compositor to do that is a surprise. But in the real world, they have to conform to a small number idioms that users recognise, and supporting those is very possible without allowing "full control". We've done some work on classifying these idioms for Mir and there's a presentation of our findings here: https://mir-server.io/docs/window-positions-under-wayland The tl;dr is that most of the idioms (regular windows, dialogs, menus, popus, tooltips, hovers, satellites, toolboxes) are already supported and there's no fundamental problem extending the existing approach used by Wayland to cover others. (Most of the support needed can be cut & paste from other idioms.)
Use-case when positioning a window is necessary
Hi, I've seen the discussion this month about positioning windows. The use-case is something concrete: the Devhelp [1] assistant window. For some background, Devhelp (and libdevhelp) is implemented flexibly: it can be used as a standalone app, it can be integrated into GTK IDEs, the standalone app can be called to search or open a symbol. And there is the Devhelp assistant window: it is typically used by a text editor, to ask Devhelp to show a small window with the documentation for the symbol under the cursor. And that is where positioning is necessary: to not occlude the line of text where the cursor is, and to show the documentation at a sensible place (near the cursor position). With Wayland, this should be implemented with a subsurface. I may be wrong, but in this case it's not possible, because it's not the same app (the same process). (For example you open a terminal, then open Vim, then you press a key and it opens the Devhelp assistant window). So, what would be your suggestion in such a use-case? To still retain the flexibility of Devhelp. Thanks, Sébastien [1] https://wiki.gnome.org/Apps/Devhelp (an API browser)
Re: Use-case when positioning a window is necessary
Hi Sébastien, On Mon, 8 Aug 2022 at 14:50, Sébastien Wilmet wrote: > Hi, > > I've seen the discussion this month about positioning windows. > > The use-case is something concrete: the Devhelp [1] assistant window. > > For some background, Devhelp (and libdevhelp) is implemented flexibly: > it can be used as a standalone app, it can be integrated into GTK IDEs, > the standalone app can be called to search or open a symbol. > > And there is the Devhelp assistant window: it is typically used by a > text editor, to ask Devhelp to show a small window with the > documentation for the symbol under the cursor. > > And that is where positioning is necessary: to not occlude the line of > text where the cursor is, and to show the documentation at a sensible > place (near the cursor position). > > With Wayland, this should be implemented with a subsurface. I may be > wrong, but in this case it's not possible, because it's not the same > app (the same process). > See the xdg-foreign protocol [2]. Cheers Olivier [2] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/xdg-foreign
Re: Use-case when positioning a window is necessary
Hello, After a quick reading of your DevHelp case, I think the issue belong devhelp and your app that using it. DevHelp have to provide an API to be embeded in another application and Wayland protocol should not be involved. Maybe d-bus can be used as pipe between DevHelp and others applications. Best Regards Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit : > Hi, > > I've seen the discussion this month about positioning windows. > > The use-case is something concrete: the Devhelp [1] assistant window. > > For some background, Devhelp (and libdevhelp) is implemented > flexibly: > it can be used as a standalone app, it can be integrated into GTK > IDEs, > the standalone app can be called to search or open a symbol. > > And there is the Devhelp assistant window: it is typically used by a > text editor, to ask Devhelp to show a small window with the > documentation for the symbol under the cursor. > > And that is where positioning is necessary: to not occlude the line > of > text where the cursor is, and to show the documentation at a sensible > place (near the cursor position). > > With Wayland, this should be implemented with a subsurface. I may be > wrong, but in this case it's not possible, because it's not the same > app (the same process). > > (For example you open a terminal, then open Vim, then you press a key > and it opens the Devhelp assistant window). > > So, what would be your suggestion in such a use-case? To still retain > the flexibility of Devhelp. > > Thanks, > Sébastien > > [1] https://wiki.gnome.org/Apps/Devhelp (an API browser)
Re: Use-case when positioning a window is necessary
Hi, On Mon, Aug 8, 2022, 8:38 AM Benoît Gschwind wrote: > Hello, > > After a quick reading of your DevHelp case, I think the issue belong > devhelp and your app that using it. DevHelp have to provide an API to > be embeded in another application and Wayland protocol should not be > involved. Maybe d-bus can be used as pipe between DevHelp and others > applications. > Problem is - DevHelp is like a plug-in- it can be used with a thousands of applications, not just a specific one. And DevHelp don't have control over them. So you reading comprehension is too fast. :-) Thank you > Best Regards > > Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit : > > Hi, > > > > I've seen the discussion this month about positioning windows. > > > > The use-case is something concrete: the Devhelp [1] assistant window. > > > > For some background, Devhelp (and libdevhelp) is implemented > > flexibly: > > it can be used as a standalone app, it can be integrated into GTK > > IDEs, > > the standalone app can be called to search or open a symbol. > > > > And there is the Devhelp assistant window: it is typically used by a > > text editor, to ask Devhelp to show a small window with the > > documentation for the symbol under the cursor. > > > > And that is where positioning is necessary: to not occlude the line > > of > > text where the cursor is, and to show the documentation at a sensible > > place (near the cursor position). > > > > With Wayland, this should be implemented with a subsurface. I may be > > wrong, but in this case it's not possible, because it's not the same > > app (the same process). > > > > (For example you open a terminal, then open Vim, then you press a key > > and it opens the Devhelp assistant window). > > > > So, what would be your suggestion in such a use-case? To still retain > > the flexibility of Devhelp. > > > > Thanks, > > Sébastien > > > > [1] https://wiki.gnome.org/Apps/Devhelp (an API browser) > >
Re: Use-case when positioning a window is necessary
On Mon, 2022-08-08 at 15:11 +0200, Olivier Fourdan wrote: > On Mon, 8 Aug 2022 at 14:50, Sébastien Wilmet > wrote: > > > > With Wayland, this should be implemented with a subsurface. I may be > > wrong, but in this case it's not possible, because it's not the same > > app (the same process). > > > > See the xdg-foreign protocol [2]. > > [2] > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/xdg-foreign Thanks! I didn't know this.
Position set/get prototype template
Hi, I started a discussion a while ago about the possibility of adding position set/get abilities to wayland, but since then I'd learned alot about how wayland works. I had heard that wayland combines the WM and server into one "compositor", but I thought wayland itself still managed some things. Since then I've learned that the compositor manages every event that a wayland client sends, and I think this makes the ability to set/get a position even more necessary. The reasons are: 1. Apps can send both the position they want for a window and and the type of window, and a compositor can choose which one to follow. (for example, a client can send (width/2, height/2) and "popup" for a popup surface, and compositors that prefer to follow the descriptive design will follow "popup" and ones that prefer prescriptive design will follow the coordinates). 2. Waylands asynchronous event system means that a compositor can ask users if they would like to give an app permission to move itself and/or other windows, similar to how android asks before giving apps camera/GPS permissions. I've looked at existing wayland protocols and used them to create a simple one for position set/get. -- Copyright © 2022 Samuel AmmoniusPermission is hereby granted, free of charge, to any person obtaining acopy of this software and associated documentation files (the "Software"),to deal in the Software without restriction, including without limitationthe rights to use, copy, modify, merge, publish, distribute, sublicense,and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice (including the nextparagraph) shall be included in all copies or substantial portions of theSoftware.THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALLTHE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISINGFROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHERDEALINGS IN THE SOFTWARE. Used to set/get the position of a surface. The ability to set the monitor that a surface is on is not available yet. Warning! The protocol described in this file is experimental and backward incompatible changes may be made. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes are done by bumping the version number in the protocol and interface names and resetting the interface version. Once the protocol is to be declared stable, the 'z' prefix and the version number in the protocol and interface names are removed and the interface version number is reset. Set the position of a surface Notification that a surface has been moved, either by itself, another program, or the compositor. WARNING: Do not use this event to force a surface to a certain position. If multiple apps want the surface in a different position, then the computer may freeze or glitch. -- Should I just send it or is my reasoning (or XML syntax) wrong?
Re: Position set/get prototype template
Hi, As we already tried to explain numerous times in the previous thread: no, we are not adding requests and events to set/get the window position. If you are interested in fixing an app which doesn't work on Wayland because of this omission, please explain your use-case, and we can discuss solutions. If you are not interested in explaining the use-cases, and are just interested in blindly adding new features: sorry, but this isn't how we want to approach things. Thanks, Simon
Re: Position set/get prototype template
Hi, Simon, On Mon, Aug 8, 2022, 9:37 AM Simon Ser wrote: > Hi, > > As we already tried to explain numerous times in the previous thread: > no, we are not adding requests and events to set/get the window position. > > If you are interested in fixing an app which doesn't work on Wayland > because of this omission, please explain your use-case, and we can > discuss solutions. > My app that I'm still building will "not" work on Wayland reliably. I tried at least 2 times to give very specific scenarios and was told to go away. No explanation, possible fixes or workarounds. Just plain "we are not doing because it's by design". I guess people (Software developers) will have to pray X11 will stay forever. Thank you. > If you are not interested in explaining the use-cases, and are just > interested in blindly adding new features: sorry, but this isn't how we > want to approach things. > > Thanks, > > Simon >
Re: Position set/get prototype template
Hi, On Mon, Aug 8, 2022, 9:27 AM samuel ammonius wrote: > Hi, > > I started a discussion a while ago about the possibility of adding > position set/get abilities to wayland, but since then I'd learned alot > about how wayland works. I had heard that wayland combines the WM and > server into one "compositor", but I thought wayland itself still managed > some things. Since then I've learned that the compositor manages every > event that a wayland client sends, and I think this makes the ability to > set/get a position even more necessary. > On top of that, the end user (a human sitting behind the monitor) can reconfigure everything, because "we all know better and computers are dumb". The reasons are: > >1. Apps can send both the position they want for a window and and the >type of window, and a compositor can choose which one to follow. (for >example, a client can send (width/2, height/2) and "popup" for a popup >surface, and compositors that prefer to follow the descriptive design will >follow "popup" and ones that prefer prescriptive design will follow the >coordinates). >2. Waylands asynchronous event system means that a compositor can ask >users if they would like to give an app permission to move itself and/or >other windows, similar to how android asks before giving apps camera/GPS >permissions. > > I've looked at existing wayland protocols and used them to create a simple > one for position set/get. > > -- > > > > Copyright © 2022 Samuel AmmoniusPermission is hereby > granted, free of charge, to any person obtaining acopy of this software > and associated documentation files (the "Software"),to deal in the > Software without restriction, including without limitationthe rights to > use, copy, modify, merge, publish, distribute, sublicense,and/or sell > copies of the Software, and to permit persons to whom theSoftware is > furnished to do so, subject to the following conditions:The above > copyright notice and this permission notice (including the nextparagraph) > shall be included in all copies or substantial portions of theSoftware. > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS IN THE SOFTWARE. > > Used to set/get the position of a surface. The > ability to set the monitor that a surface is on is not available yet. > > > Warning! The protocol described in this file is experimental and > backward incompatible changes may be made. Backward compatible changes > may be added together with the corresponding interface version bump. > Backward incompatible changes are done by bumping the version number in > the protocol and interface names and resetting the interface version. > Once the protocol is to be declared stable, the 'z' prefix and the > version number in the protocol and interface names are removed and the > interface version number is reset. > > > Set the position of a surface > >summary="target surface"/> > > > > > >Notification that a surface has been moved, either by > itself, another program, or the compositor. > > WARNING: Do not use this event to force a surface to a certain > position. If multiple apps want the surface in a different position, then the > computer may freeze or glitch. > > > > > > > > > > > > > > > > > > > > > > -- > > Should I just send it or is my reasoning (or XML syntax) wrong? > >
Re: Position set/get prototype template
Or even better - when one of you will need to quickly create a "proof-of-concept" application that will jump all over the places on every startup... Thank you. On Mon, Aug 8, 2022, 9:37 AM Simon Ser wrote: > Hi, > > As we already tried to explain numerous times in the previous thread: > no, we are not adding requests and events to set/get the window position. > > If you are interested in fixing an app which doesn't work on Wayland > because of this omission, please explain your use-case, and we can > discuss solutions. > > If you are not interested in explaining the use-cases, and are just > interested in blindly adding new features: sorry, but this isn't how we > want to approach things. > > Thanks, > > Simon >
Re: Position set/get prototype template
Igor, On Mon, 8 Aug 2022 at 15:54, Igor Korot wrote: > Or even better - when one of you will need to quickly create a > "proof-of-concept" application that will jump all over the places on every > startup... We've written applications for years. We know how to make it work. We've explained to you how to make it work. It may not work in the exact way you have in your head, but the real usecases can and do work, even if you won't listen to patient explanations. This discussion has more than run its course by now. Unfortunately as you seem hellbent on continuing to repeat the same thing over and over without listening to anything else being said, your posts will now be moderated. Cheers, Daniel
Re: Position set/get prototype template
Hi, On Mon, Aug 8, 2022 at 12:06 PM Simon Ser wrote: > If you are not interested in explaining the use-cases, and are just > interested in blindly adding new features: sorry, but this isn't how we > want to approach things. Sorry for not giving a more specific answer to this earlier. The main reason is regarding an app's location when it starts up. For example, a large workspace application like VS-Studio or Blender may want to start maximized, but not full screen. AFAIK, Wayland has a protocol for fullscreen but not for maximizing/minimizing an app, so this can only be done by setting the position to (0, 0) and setting the size to the viewport size of the compositor. Other apps may want to start where they left off. I know that this is something that the compositor should handle by default, but many of them don't. The largest obstacle is that apps like screenshot utilities may want to start in the top left, autoclickers start in the top right, console applications start in the center when opened with ALT+T, and many other small situations like. There are probably many other scenarios like this, and it seems like an unnecessary amount of pain to add a new protocol every time a new thing pops up. Anyways, I don't see the harm in adding this feature. Who says that a compositor is any smarter than an app? Many compositors don't support remembering a window's location, while many apps do. Apps aren't users, so taking power away from them isn't "making things simpler". On Mon, Aug 8, 2022 at 1:13 PM Daniel Stone wrote: > Igor, > > On Mon, 8 Aug 2022 at 15:54, Igor Korot wrote: > > Or even better - when one of you will need to quickly create a > "proof-of-concept" application that will jump all over the places on every > startup... > > We've written applications for years. We know how to make it work. > We've explained to you how to make it work. It may not work in the > exact way you have in your head, but the real usecases can and do > work, even if you won't listen to patient explanations. > > This discussion has more than run its course by now. Unfortunately as > you seem hellbent on continuing to repeat the same thing over and over > without listening to anything else being said, your posts will now be > moderated. > > Cheers, > Daniel >
Re: Position set/get prototype template
Hi Samuel, On Mon, 8 Aug 2022 at 17:04, samuel ammonius wrote: > On Mon, Aug 8, 2022 at 12:06 PM Simon Ser wrote: >> If you are not interested in explaining the use-cases, and are just >> interested in blindly adding new features: sorry, but this isn't how we >> want to approach things. > > Sorry for not giving a more specific answer to this earlier. The main reason > is regarding an app's location when it starts up. For example, a large > workspace application like VS-Studio or Blender may want to start maximized, > but not full screen. AFAIK, Wayland has a protocol for fullscreen but not for > maximizing/minimizing an app Wayland does have a protocol for maximising apps. Without it, we wouldn't have been able to ship as the default desktop for every mainline distribution for several years now. I recommend you look into the xdg-shell family of protocols. Introductory guides to Wayland will also cover this. > ... so this can only be done by setting the position to (0, 0) and setting > the size to the viewport size of the compositor. Other apps may want to start > where they left off. I know that this is something that the compositor should > handle by default, but many of them don't. The largest obstacle is that apps > like screenshot utilities may want to start in the top left, autoclickers > start in the top right, console applications start in the center when opened > with ALT+T, and many other small situations like. There are probably many > other scenarios like this, and it seems like an unnecessary amount of pain to > add a new protocol every time a new thing pops up. > > Anyways, I don't see the harm in adding this feature. Who says that a > compositor is any smarter than an app? Many compositors don't support > remembering a window's location, while many apps do. Apps aren't users, so > taking power away from them isn't "making things simpler". It's not taking any power away from apps. It's giving the entire ecosystem more power. It takes more work to achieve than just blindly taking the shortest possible path, but conversely it also saves us from being painted into the same corners that made X11 no longer viable. Cheers, Daniel
Re: Position set/get prototype template
Hi Daniel, I've just looked at the xdg-shell protocol as you said. I was really surprised at the amount of features it had, but one part in particular caught my eye: The window geometry of a surface is its "visible bounds" from theuser's perspective. Client-side decorations often have invisibleportions like drop-shadows which should be ignored for thepurposes of aligning, placing and constraining windows. The window geometry is double buffered, and will be applied at thetime wl_surface.commit of the corresponding wl_surface is called. Once the window geometry of the surface is set, it is not possible to unset it, and it will remain the same until set_window_geometry is called again, even if a new subsurface or buffer is attached. If never set, the value is the full bounds of the surface, including any subsurfaces. This updates dynamically on everycommit. This unset is meant for extremely simple clients.The arguments are given in the surface-local coordinate space of the wl_surface associated with this xdg_surface.The width and height must be greater than zero. Setting an invalid size will raise an error. When applied, the effective window geometry will be the set window geometry clamped to the bounding rectangle of thecombined geometry of the surface of the xdg_surface and the associated subsurfaces. * <--- > > <---* type="int"/> > > Doesn't this mean that Wayland already supports this?
Re: Position set/get prototype template
(I forgot to mention in the above message that I was looking at the unstable version) On Mon, Aug 8, 2022 at 1:54 PM samuel ammonius wrote: > Hi Daniel, > > I've just looked at the xdg-shell protocol as you said. I was really > surprised at the > amount of features it had, but one part in particular caught my eye: > >The window geometry of a surface is its "visible > bounds" from the user's perspective. Client-side decorations often have > invisibleportions like drop-shadows which should be ignored for the >purposes of aligning, placing and constraining windows. The window > geometry is double buffered, and will be applied at the time > wl_surface.commit of the corresponding wl_surface is called. Once the > window geometry of the surface is set, it is not possible to unset it, and > it will remain the same until set_window_geometry is called again, even > if a new subsurface or buffer is attached. If never set, the value is the > full bounds of the surface, including any subsurfaces. This updates > dynamically on everycommit. This unset is meant for extremely simple > clients. The arguments are given in the surface-local coordinate space > ofthe wl_surface associated with this xdg_surface.The width > and height must be greater than zero. Setting an invalid size will raise an > error. When applied, the effective window geometry will bethe set > window geometry clamped to the bounding rectangle of thecombined > geometry of the surface of the xdg_surface and the associated subsurfaces. >* > <--- >> >> <---* > type="int"/> >> >> Doesn't this mean that Wayland already supports this? >
Re: Position set/get prototype template
On Mon, 8 Aug 2022 at 17:24, samuel ammonius wrote: > I've just looked at the xdg-shell protocol as you said. I was really > surprised at the > amount of features it had, but one part in particular caught my eye: Window geometry is relative to surface co-ordinates. As the first paragraph describes, it is used to describe the region of the surface which excludes external decor like drop shadows. One thing you might note is that Wayland does not supply a global co-ordinate space to clients. Everything is supplied in a surface co-ordinate space. Again, this will become clear if you took the time to work through an introductory guide to Wayland. Think of it this way: the developers are giving you their time and effort by explaining to you how Wayland works, and trying to guide you through why your proposed designs are unworkable. It would be very polite if you could repay the favour by investing some of your time and effort to understand Wayland before proposing drastic changes to it and demanding the developers justify why they won't be accepted. Cheers, Daniel
Re: Position set/get prototype template
On Mon, 8 Aug 2022 16:42:02 +0100 Daniel Stone said: > Igor, > > On Mon, 8 Aug 2022 at 15:54, Igor Korot wrote: > > Or even better - when one of you will need to quickly create a > > "proof-of-concept" application that will jump all over the places on every > > startup... > > We've written applications for years. We know how to make it work. > We've explained to you how to make it work. It may not work in the > exact way you have in your head, but the real usecases can and do > work, even if you won't listen to patient explanations. > > This discussion has more than run its course by now. Unfortunately as > you seem hellbent on continuing to repeat the same thing over and over > without listening to anything else being said, your posts will now be > moderated. What Daniel said. My mistake for putting fuel on the fire and explaining why Wayland does not have explicit positioning. I hoped to provide some explaining of the history of pain that led up to things being this way (and there are decades of experience per experienced Wayland developer who supports this). We've all done everything from display servers to window managers to compositors, toolkits, applications and more for many decades. Solve the corner cases not already solved. Don't do "give me a sledgehammer to break the world with" with explicit positioning. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Position set/get prototype template
Hi Igor, I don't understand why you would want to be able to control where a dialog goes. I'd normally agree that applications should be given the option to do whatever they want, but a dialog is literally the worst example possible second only to splash screens. Wayland allows the user to control weather all dialogs should be centred in the screen or in their parent application. Why is this a bad thing? OR do what the > user has explicitly configured it to do because the user wants something > broken (and the compositor allows it), This was only supposed to mean that users are able to configure their compositor in strange ways and still have all apps behave the same. Normally I'd argue that apps should still be given the option to ignore these preferences (or at least a standard way to *ask* the compositor if it can ignore them), but not with dialogs. I'm assuming you're talking about Yes/No-type dialogs.
Re: Use-case when positioning a window is necessary
On Mon, 2022-08-08 at 15:37 +0200, Benoît Gschwind wrote: > > After a quick reading of your DevHelp case, I think the issue belong > devhelp and your app that using it. DevHelp have to provide an API to > be embeded in another application and Wayland protocol should not be > involved. Maybe d-bus can be used as pipe between DevHelp and others > applications. The summary is as below: > Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit : > > With Wayland, this should be implemented with a subsurface. I may be > > wrong, but in this case it's not possible, because it's not the same > > app (the same process). > > > > (For example you open a terminal, then open Vim, then you press a key > > and it opens the Devhelp assistant window). As Olivier suggested, the xdg-foreign protocol would be a solution. I don't know if it's easy to implement, in a general way *from* any app (terminal etc) *to* Devhelp. But at least I know that it's feasible, and that Wayland supports it. Your solution might work as well, I don't know. Cheers, Sébastien
Re: Window positions under wayland
Thanks. I read https://mir-server.io/docs/window-positions-under-wayland, Is your standpoint by adding more shell protocols to support windows that behave differently rather than allowing the client to take full control window position to implement some special behavior? Agree, wayland should maintain its current design goals. --JiDe Zhang -- linuxdeepin.