Re: [PATCH] Introduce set_size_hints xdg_surface request.
On Thu, 7 Aug 2014 17:18:54 +0300 Jari Vetoniemi mailro...@gmail.com wrote: What is the default value of these hints? I would propose -1 as default, meaning unset. Compositor has to deal with not knowing the minimum size, preferably this would mean though that the client can be set to any valid size. When is the client expected to send this? Can this be sent before the window gets mapped? After the window was unmapped? I would say this hint could be sent any time after surface object is created. How does this interact with the protocol sequence to decide the initial size of a window before it gets mapped? If the maximum was less than initial size, this would need thinking. For now it seems though that maximum might go away? My main question here was, how does the protocol sequence look like? A client creates a wl_surface and a xdg_surface for it. What does the following protocol sequence look like, when negotiating the initial window size, leading to mapping the window the first time? Does the server send a configure event immediately as a reply to creating the xdg_surface? If yes, does the compositor send a new configure event after the client has sent the size hint request? If the client sends the request to create xdg_surface immediately followed by the request to set size hints, how does the client know if the next configure event it receives is before or after the compositor saw the size hint? Does it even matter? Or do you require a round-trip: the client must wait for the first configure event before sending the size hints, so that it knows the next configure event is with size hints applied? (I would like to avoid round-trips whenever sanely possible.) Needs further discussion. Making surface state double-buffered is desired for all state that immediately affects the surface's presentation. However, these are hints and do not change how the surface is presented; they change what sizes the compositor may ask for in configure events. It that sense, it is not necessary to make this state double-buffered, and I think not double-buffering (not demanding a commit) will make it easier to use and also to define how it works with the initial size negotiation. I agree with this, I don't see any reason for this to be double-buffered either to be honest. Otherwise seems ok AFAIU. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
Bill, you again managed to drop people from CC. Please do not do that. On Thu, 07 Aug 2014 12:43:17 -0700 Bill Spitzak spit...@gmail.com wrote: On 08/07/2014 07:18 AM, Jari Vetoniemi wrote: What is the default value of these hints? I think you could get away with defaulting the minimum to be about 100x100. I think that is sufficient to get clients to work ok and it is small enough to encourage them to set this rather than relying on the default. I really don't think we want to encode that into the protocol specification. Unset is the right answer here. The compositor can have its own preferences, and you can have your 100x100 limit there. Nothing says the compositor must use the minimum hint size for initial size, and I expect most compositors will also not do so. If the surface is currently smaller than the minimum it should act like the current size is the minimum. How does this interact with the protocol sequence to decide the initial size of a window before it gets mapped? These should have no effect. The client is free to supply sizes outside the range it claims. And the compositor is free to request them. It is only a hint. Not exactly always. And yes, like in my rephrased question, there is very definitely an interaction, or you may see a size change glitch on opening new windows. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
On 08/08/2014 12:00 AM, Pekka Paalanen wrote: Bill, you again managed to drop people from CC. Please do not do that. I am not sure what is up with Thunderbird here. The problem was that I responded to my own post. In addition it refuses to show reply-all or reply-to-list to any of my git send-email patch sets. I have tried manually adding the list id and nothing makes a difference. I will try to make sure the cc list is copied (it is working for this reply...) On Thu, 07 Aug 2014 12:43:17 -0700 Bill Spitzak spit...@gmail.com wrote: On 08/07/2014 07:18 AM, Jari Vetoniemi wrote: What is the default value of these hints? I think you could get away with defaulting the minimum to be about 100x100. I think that is sufficient to get clients to work ok and it is small enough to encourage them to set this rather than relying on the default. I really don't think we want to encode that into the protocol specification. Unset is the right answer here. Sorry that was poorly stated. What I meant is that the implementation can just treat unset as 100x100 (or any other value it wants). I don't think it needs to do anything more complicated for unset values, since any such complication should be something the client can communicate. This means that the implementation does not need any unset value, it can just init the data to 100,100 (or whatever). It might help if the tiling window manager treated the minimum size as the smaller of the surface's current size and it's declared minimum. That would allow the default minimum to be much larger. How does this interact with the protocol sequence to decide the initial size of a window before it gets mapped? These should have no effect. The client is free to supply sizes outside the range it claims. And the compositor is free to request them. It is only a hint. Not exactly always. And yes, like in my rephrased question, there is very definitely an interaction, or you may see a size change glitch on opening new windows. The tiling window manager has to send a configure event with the desired size before showing the surface. Only the window manager knows what size it wants the surface. In a correctly working system it can block the update until all the clients respond with resized surfaces (obviously there are timeouts and dead clients, but that problem is true of all changes to the window layout, not just the ones due to the minimum size changing). I think this sequence works: 1. Client creates wl_surface and xdg_shell_surface 2. Client sends minimum size 3. Client creates buffer at the size it wants, draws, and commits it 4. Compositor probably cannot handle that size. It sends configure event to the client (and all the other clients since the mapping of the new surface probably changed things). It could sent the configure event before the commit if it can figure it out without the buffer size. 5. Client resizes the buffer to new size, draws, and commits it 6. Compositor redraws the screen after all the clients respond or time out. Though it seems like the first drawing is a waste of time, I don't see any way to avoid it. The compositor must have a buffer, because it needs a fallback if the client fails to respond to the configure request before the timeout. And currently this is where the desired size (which may be different than the minimum) is sent. Also any other scheme will needlessly slow down non-tiled window management by requiring a round-trip before the client can draw the first surface. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
Relying only on maximized/fullscreen states to do tiling or hiding decorations feels bit nasty, as for client developers it's documented that fullscreen and maximized are indeed what they are. For example fullscreen application such as video player could hide controls in fullscreen mode, which is not desirable. These all would be relying on implementation detail that could break if client developer did things bit differently, but still according to documentation. As for maximum size, only use case I could come up with it is for widget sort of applications that are supposed to be certain size, but I would not bet my life on its usefulness. We are working things on one step at a time. Jari was working on a tiling WM using the maximized state. Yeah, I'll keep working on this more so we can pinpoint all the problem points implementing tiling wms with the current interfaces. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
On Tue, 5 Aug 2014 22:07:39 +0300 Jari Vetoniemi mailro...@gmail.com wrote: Rationale for this patch is to provide way for applications that can't go below/above certain bounds to inform compositor about it. More feedback is needed. For example are maximimum size useful for any particular application? --- protocol/xdg-shell.xml | 18 ++ 1 file changed, 18 insertions(+) Hi, I have a few technical questions. diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml index bd36231..6e48ae6 100644 --- a/protocol/xdg-shell.xml +++ b/protocol/xdg-shell.xml @@ -235,6 +235,24 @@ arg name=edges type=uint summary=which edge or corner is being dragged/ /request +request name=set_size_hints + description summary=provide surface size hints +Server should use these hints to figure out how much surface may be, +resized so that the content still remains sane. Hints will remain +the same until set_size_hints is requested again. + +Hints set this way are double buffered. They will get applied on +the next commit. + +These hints should take effect regardless of the surface state. +A size less than zero unsets the hint. What is the default value of these hints? When is the client expected to send this? Can this be sent before the window gets mapped? After the window was unmapped? How does this interact with the protocol sequence to decide the initial size of a window before it gets mapped? Making surface state double-buffered is desired for all state that immediately affects the surface's presentation. However, these are hints and do not change how the surface is presented; they change what sizes the compositor may ask for in configure events. It that sense, it is not necessary to make this state double-buffered, and I think not double-buffering (not demanding a commit) will make it easier to use and also to define how it works with the initial size negotiation. Thanks, pq + /description + arg name=min_width type=int summary=minimum width of the surface/ + arg name=min_height type=int summary=minimum height of the surface/ + arg name=max_width type=int summary=maximum width of the surface/ + arg name=max_height type=int summary=maximum height of the surface/ +/request + enum name=state description summary=types of state on the surface The different state values used on the surface. This is designed for ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
What is the default value of these hints? I would propose -1 as default, meaning unset. Compositor has to deal with not knowing the minimum size, preferably this would mean though that the client can be set to any valid size. When is the client expected to send this? Can this be sent before the window gets mapped? After the window was unmapped? I would say this hint could be sent any time after surface object is created. How does this interact with the protocol sequence to decide the initial size of a window before it gets mapped? If the maximum was less than initial size, this would need thinking. For now it seems though that maximum might go away? Needs further discussion. Making surface state double-buffered is desired for all state that immediately affects the surface's presentation. However, these are hints and do not change how the surface is presented; they change what sizes the compositor may ask for in configure events. It that sense, it is not necessary to make this state double-buffered, and I think not double-buffering (not demanding a commit) will make it easier to use and also to define how it works with the initial size negotiation. I agree with this, I don't see any reason for this to be double-buffered either to be honest. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
On 08/07/2014 07:18 AM, Jari Vetoniemi wrote: What is the default value of these hints? I think you could get away with defaulting the minimum to be about 100x100. I think that is sufficient to get clients to work ok and it is small enough to encourage them to set this rather than relying on the default. If the surface is currently smaller than the minimum it should act like the current size is the minimum. How does this interact with the protocol sequence to decide the initial size of a window before it gets mapped? These should have no effect. The client is free to supply sizes outside the range it claims. And the compositor is free to request them. It is only a hint. Under ICCCM and some X window managers it was literally impossible to change the minimum size because they refused to set it smaller than the window, and would also refuse to set the window smaller than the minimum. That was very frustrating. Please don't do things like that. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
This doesn't work in the case of tiling WMs which may want some up-front information about window sizes so they can lay them out correctly. Currently, we say that the maximize and fullscreen states are strictly sized, and clients *must* submit window geometry that's equivalent to that, so there needs to be some negotiation from the point of the client so it can say that it won't render a buffer at a silly size. Some tiling WMs may still need to force the client sizes on certain layouts. However this is better than nothing, as the tiling wm actually has clue when the client would be rendered incorrectly and when not. This is also better as trying to workaround, by checking whether client responded to your resize request or not and figuring out the bounds yourself, as the client may not be responding for other reasons. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
I can see a minimum size being useful for this, but not a maximum. Compositors are allowed to request sizes smaller than this, and cannot assume clients will not resize surfaces smaller than this. It is just advisory for layout. Compositors could assume the initial size is the minimum if it is never given. A useful addition would be something to the configure event that says whether the horizontal or vertical size is more important. Many clients have a minimum in one dimension that depends on the other dimension (imagine a filled paragraph of text, it gets taller as it gets narrower). This relationship is much too complicated to communicate to the compositor so it will have to be done with round trips, I don't think round trips can be avoided. Dead clients are detectable with the ping/pong api. A tiling window manager would use the minimum size to decide the thickness of a row or column of clients. It would then use a round trip to get the actual size in the opposite direction. An extra round trip would be needed for the last client in the row or column to make it fill the hole. After that it should just clip or pad the surfaces to fit. Until all the round trips are done the compositor continues to display the previous display and does not release the previous buffers. On 08/06/2014 01:42 AM, Jari Vetoniemi wrote: This doesn't work in the case of tiling WMs which may want some up-front information about window sizes so they can lay them out correctly. Currently, we say that the maximize and fullscreen states are strictly sized, and clients *must* submit window geometry that's equivalent to that, so there needs to be some negotiation from the point of the client so it can say that it won't render a buffer at a silly size. Some tiling WMs may still need to force the client sizes on certain layouts. However this is better than nothing, as the tiling wm actually has clue when the client would be rendered incorrectly and when not. This is also better as trying to workaround, by checking whether client responded to your resize request or not and figuring out the bounds yourself, as the client may not be responding for other reasons. ___ 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: [PATCH] Introduce set_size_hints xdg_surface request.
Never mind my previous response. I just tried a bunch of programs that implement tiling internally, and only one of them (a Mail program with very simple set of 3 tiles) made a tile taller as it got narrower. All others just introduce scroll bars. Since these are programs with complete control and knowledge of their contents, it appears that it is too hard to do the complex resizing I was suggesting, especially for unknown clients. So it seems ok to have the client send a minimum size to the compositor. The tiled compositor will figure out the layout based only on it's state and the minimum sizes of all the clients. No round trips. It is still important that clients know the compositor may configure smaller than the minimum, and compositors to know that clients may resize the surface smaller too. If the compositor requests a size that is too small, the client is expected to add scrollbars. If the contents reflow then it will probably manage to add a scrollbar in only one direction (this is why the client must do the scrollbars, not the compositor). If the client makes the surface larger than requested, the tiled window manager can clip or scale it to fit. I am unsure if a maximum size is wanted. If a client actually has a maximum size it will just make the surface that size when a larger size is requested. The tiled window manager can then pad it with rectangles, this does not add any round trips. I could not find any program where the tiles act like there is a maximum size, and it is difficult to see what could be done with this information, for instance if a surface with no maximum size is in the same row/column. There is also the problem that you have to do something unintuitive to indicate there is no maximum size. So I would remove this, perhaps making it a different request in the future. A tiled window manager also needs an api to tell the client to not draw edges and the shadow. This is also useful for maximized and fullscreen. Turning the titlebar on/off would be a different control, some tiled window managers may want to keep it. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
On Wed, Aug 6, 2014 at 8:28 PM, Bill Spitzak spit...@gmail.com wrote: Never mind my previous response. I just tried a bunch of programs that implement tiling internally, and only one of them (a Mail program with very simple set of 3 tiles) made a tile taller as it got narrower. All others just introduce scroll bars. Since these are programs with complete control and knowledge of their contents, it appears that it is too hard to do the complex resizing I was suggesting, especially for unknown clients. So it seems ok to have the client send a minimum size to the compositor. The tiled compositor will figure out the layout based only on it's state and the minimum sizes of all the clients. No round trips. Yeah, the complexities of height-for-width layout means that there is no independent minimum width/height, only a minimum area, but that sort of constraint system is difficult to express to a compositor, and most clients should be able to come up with one minimum size, however large or small it might be. It is still important that clients know the compositor may configure smaller than the minimum, and compositors to know that clients may resize the surface smaller too. If the compositor requests a size that is too small, the client is expected to add scrollbars. If the contents reflow then it will probably manage to add a scrollbar in only one direction (this is why the client must do the scrollbars, not the compositor). If the client makes the surface larger than requested, the tiled window manager can clip or scale it to fit. For the maximized or fullscreen states, the client must always submit window geometry that is the configured size. No exceptions. I am unsure if a maximum size is wanted. If a client actually has a maximum size it will just make the surface that size when a larger size is requested. The tiled window manager can then pad it with rectangles, this does not add any round trips. I could not find any program where the tiles act like there is a maximum size, and it is difficult to see what could be done with this information, for instance if a surface with no maximum size is in the same row/column. There is also the problem that you have to do something unintuitive to indicate there is no maximum size. So I would remove this, perhaps making it a different request in the future. Yeah, we were debating on IRC about the utility of a max_size. I don't think it's necessary, but I figured we would look around and see if any other clients used it. The only case I could think of is an unresizable client, in which case it would set the minimum and maximum sizes to be the same. I think we should handle that with a separate system. A tiled window manager also needs an api to tell the client to not draw edges and the shadow. This is also useful for maximized and fullscreen. Turning the titlebar on/off would be a different control, some tiled window managers may want to keep it. One step at a time. We'll get there. ___ 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: [PATCH] Introduce set_size_hints xdg_surface request.
On 08/06/2014 05:38 PM, Jasper St. Pierre wrote: For the maximized or fullscreen states, the client must always submit window geometry that is the configured size. No exceptions. Are you sure? I know the fullscreen supports scaling or centering of a smaller surface (though the client has to set the resize type first). What happens if the size is wrong? Is the client killed with a protocol error? It is true that fullscreen and maximized are in fact tiled window managers. Any ideas for these and for tiled window managers apply to each other and the api should be the same. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
On Wed, Aug 6, 2014 at 9:30 PM, Bill Spitzak spit...@gmail.com wrote: On 08/06/2014 05:38 PM, Jasper St. Pierre wrote: For the maximized or fullscreen states, the client must always submit window geometry that is the configured size. No exceptions. Are you sure? I know the fullscreen supports scaling or centering of a smaller surface (though the client has to set the resize type first). What happens if the size is wrong? Is the client killed with a protocol error? The scaling system was removed in xdg-shell. If we want to add it back, we should probably look more closely at the zoom and crop extension for scaling surfaces. It is not a protocol error to submit incorrect window geometry right now, but we might want to make it one eventually. The case of undefined or invalid values in protocols needs more semantics, and I'm going to talk more about this tomorrow in my reply to Pekka. It is true that fullscreen and maximized are in fact tiled window managers. Any ideas for these and for tiled window managers apply to each other and the api should be the same. We are working things on one step at a time. Jari was working on a tiling WM using the maximized state. We will introduce new states as the needs arise. Currently, hacking something up with maximized was enough to get a prototype out, but there was certainly talk about doing more here. -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
This should not be necessary. Client can just ignore the requested size and make the buffer the size it wants. On 08/05/2014 12:07 PM, Jari Vetoniemi wrote: Rationale for this patch is to provide way for applications that can't go below/above certain bounds to inform compositor about it. More feedback is needed. For example are maximimum size useful for any particular application? --- protocol/xdg-shell.xml | 18 ++ 1 file changed, 18 insertions(+) diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml index bd36231..6e48ae6 100644 --- a/protocol/xdg-shell.xml +++ b/protocol/xdg-shell.xml @@ -235,6 +235,24 @@ arg name=edges type=uint summary=which edge or corner is being dragged/ /request +request name=set_size_hints + description summary=provide surface size hints +Server should use these hints to figure out how much surface may be, +resized so that the content still remains sane. Hints will remain +the same until set_size_hints is requested again. + +Hints set this way are double buffered. They will get applied on +the next commit. + +These hints should take effect regardless of the surface state. +A size less than zero unsets the hint. + /description + arg name=min_width type=int summary=minimum width of the surface/ + arg name=min_height type=int summary=minimum height of the surface/ + arg name=max_width type=int summary=maximum width of the surface/ + arg name=max_height type=int summary=maximum height of the surface/ +/request + enum name=state description summary=types of state on the surface The different state values used on the surface. This is designed for ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce set_size_hints xdg_surface request.
This doesn't work in the case of tiling WMs which may want some up-front information about window sizes so they can lay them out correctly. Currently, we say that the maximize and fullscreen states are strictly sized, and clients *must* submit window geometry that's equivalent to that, so there needs to be some negotiation from the point of the client so it can say that it won't render a buffer at a silly size. On Tue, Aug 5, 2014 at 9:11 PM, Bill Spitzak spit...@gmail.com wrote: This should not be necessary. Client can just ignore the requested size and make the buffer the size it wants. On 08/05/2014 12:07 PM, Jari Vetoniemi wrote: Rationale for this patch is to provide way for applications that can't go below/above certain bounds to inform compositor about it. More feedback is needed. For example are maximimum size useful for any particular application? --- protocol/xdg-shell.xml | 18 ++ 1 file changed, 18 insertions(+) diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml index bd36231..6e48ae6 100644 --- a/protocol/xdg-shell.xml +++ b/protocol/xdg-shell.xml @@ -235,6 +235,24 @@ arg name=edges type=uint summary=which edge or corner is being dragged/ /request +request name=set_size_hints + description summary=provide surface size hints +Server should use these hints to figure out how much surface may be, +resized so that the content still remains sane. Hints will remain +the same until set_size_hints is requested again. + +Hints set this way are double buffered. They will get applied on +the next commit. + +These hints should take effect regardless of the surface state. +A size less than zero unsets the hint. + /description + arg name=min_width type=int summary=minimum width of the surface/ + arg name=min_height type=int summary=minimum height of the surface/ + arg name=max_width type=int summary=maximum width of the surface/ + arg name=max_height type=int summary=maximum height of the surface/ +/request + enum name=state description summary=types of state on the surface The different state values used on the surface. This is designed for ___ 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
