seprate window management component
-- Forwarded message -- From: cat zixo...@gmail.com Date: Thu, Sep 15, 2011 at 7:27 AM Subject: Re: seprate window management component To: Michal Suchanek hramr...@centrum.cz On Thu, Sep 15, 2011 at 4:03 AM, Michal Suchanek hramr...@centrum.cz wrote: On 14 September 2011 18:21, cat zixo...@gmail.com wrote: well if clients are allowed to decide how their own windows stack, the window management proxy would be in control. the idea I have is that there isn't any special protocol changes (though that might be bad for this system), but because of the proxy, a call to or a response from (or lack of one) a client could be corrected, and nether the final display server nor the client know that such a correction took place. Still the clients should not know about the windows of other clients so they would not know how their windows stack and not knowing that they can't really decide it either. They should be able to decide relative stacking of their windows so if a document window is raised, the client is notified of that, and the client responds by raising its toolbar windows it might work. if the proxy is the only client of the real server, and its windows are all the windows of the real client, then it has the real window list, it can enforce that on the server without having to know of other windows. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: seprate window management component
Michal Suchanek wrote: Still the clients should not know about the windows of other clients so they would not know how their windows stack and not knowing that they can't really decide it either. I don't think the clients will know about any windows other than a few ids that the compositor tells them about. By default they can only put windows immediatly above or below another window they own, or put them at the top/bottom of the stack by passing None for the other window. They should be able to decide relative stacking of their windows so if a document window is raised, the client is notified of that, and the client responds by raising its toolbar windows it might work. The client needs to be able to do the raise, it can't just respond to the raise from the compositor. This is because it may want to raise or map other windows above the raised one, and this must either be done first, or atomically with, the raise of the main window. If this is not done, the floating windows will blink which is unacceptable. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: seprate window management component
On Wed, Sep 14, 2011 at 11:19 PM, Michal Suchanek hramr...@centrum.cz wrote: Hello, On 14 September 2011 16:55, cat zixo...@gmail.com wrote: would it be to much trouble to make window management a proxy program? The wayland server has to know how the windows stack but the clients are not trusted to tell it how the windows should stack so either the server has to figure that out by itself or a separate privileged component (eg. a proxy or a plugin or attached process of some sort) would need to decide that. I thought that it would make sense to determine what policy needs to be decided by this manager and add protocol for it in Wayland even if the default implementation will just grant every request an application ever makes. When I asked about that it was not outright rejected but there was nobody else who though putting some structure into Wayland would be of any use. I guess this will be considered only after Wayland evolves so many warts as X has and putting some sanity in the protocol will be impossible at that point for reasons of backward compatibility and whatnot. The biggest problem with the X protocol is that you talk to the window manager by making requests to the server and having them redirected by the window manager. Then the window manager being priviledged for that window (see SubstructureRedirectMask) is able to make requests to the server and have them be processed without redirect. This approach is somewhat inflexible and brings problems with eg, override redirect windows and out-of-order bugs when processing ConfigureRequests for normal windows and only receiving a ConfigureNotify for override redirect windows. In any case, the protocol for talking to the window manager should be part of a separate API that functions outside of the compositor. I think whether or not this is done out of process or in process is simply a matter of implementation. (In this process at least, all window management related requests would go through the window management policy first, rather than having the situation where we do now where the window manager must process requests after the fact in some cases) Regards, Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: seprate window management component
Hello, On 14 September 2011 16:55, cat zixo...@gmail.com wrote: would it be to much trouble to make window management a proxy program? The wayland server has to know how the windows stack but the clients are not trusted to tell it how the windows should stack so either the server has to figure that out by itself or a separate privileged component (eg. a proxy or a plugin or attached process of some sort) would need to decide that. I thought that it would make sense to determine what policy needs to be decided by this manager and add protocol for it in Wayland even if the default implementation will just grant every request an application ever makes. When I asked about that it was not outright rejected but there was nobody else who though putting some structure into Wayland would be of any use. I guess this will be considered only after Wayland evolves so many warts as X has and putting some sanity in the protocol will be impossible at that point for reasons of backward compatibility and whatnot. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: seprate window management component
well if clients are allowed to decide how their own windows stack, the window management proxy would be in control. the idea I have is that there isn't any special protocol changes (though that might be bad for this system), but because of the proxy, a call to or a response from (or lack of one) a client could be corrected, and nether the final display server nor the client know that such a correction took place. to better enforce the use of such a proxy, a display server could only accept a connection from one client On Wed, Sep 14, 2011 at 10:19 AM, Michal Suchanek hramr...@centrum.cz wrote: Hello, On 14 September 2011 16:55, cat zixo...@gmail.com wrote: would it be to much trouble to make window management a proxy program? The wayland server has to know how the windows stack but the clients are not trusted to tell it how the windows should stack so either the server has to figure that out by itself or a separate privileged component (eg. a proxy or a plugin or attached process of some sort) would need to decide that. I thought that it would make sense to determine what policy needs to be decided by this manager and add protocol for it in Wayland even if the default implementation will just grant every request an application ever makes. When I asked about that it was not outright rejected but there was nobody else who though putting some structure into Wayland would be of any use. I guess this will be considered only after Wayland evolves so many warts as X has and putting some sanity in the protocol will be impossible at that point for reasons of backward compatibility and whatnot. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: seprate window management component
On 15/09/11 04:33, Michal Suchanek wrote: On 14 September 2011 20:26, Bill Spitzakspit...@gmail.com wrote: I think the idea is that what you are calling the window manager is in fact a library running in the client process and memory space. It would probably be part of the toolkit. Which is utterly wrong. 1) you can't deal with clients malfunctioning 2) now every toolkit would not only look differently but also behave differently, possibly to the point that when running applications using multiple different toolkits your desktop breaks due to WM incompatibility 3) this is not really toolkit specific and should not have to be reimplemented in every toolkit If implementing something in the toolkit makes things easier, then i don't see why that shouldn't be done. All that's needed for consistancy between toolkits is a standard to follow. I wouldn't want policy imposed on my toolkit by an external server i don't like. IIRC, the X icccm defines properties for window groups, and it is up to the application to set those properties correctly and that the WM does the right thing. If they don't do the right thing or are malfunctioning, then just fix them or create an alternative. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
