Re: client side decorations
On Sat, May 7, 2011 at 12:52 PM, microcai micro...@fedoraproject.orgwrote: 于 2011年05月08日 00:30, Mike Paquette 写道: On May 7, 2011, at 8:40 AM, microcai wrote: I know some basic theory of compositor. But I still have concern about client window decorations. I think it is very likely an application becomes unresponsive during resizing. Or a user tires to resize a unresponsive window. In that case, I don't know if compositor can draw an updated title bar or just stretch the outdated window context to the new size. At same time how the compositor calculate rectangles' size and position for title bar and buttons? Peng Like I said, the compositor can call the client unconditional via signal. No matter it is live or dead lock. I'm not entirely sure this is a workable idea. Signals are not a reliable inter-process communications mechanism. There are also limits as to what state can be safely modified from within a signal handler. Non-async-signal-safe functions cannot be invoked from a signal handler. That would include functions that alter graphics state. A normal thread of execution within a client may not be coded to anticipate asynchronous modification of the current graphics state. The use of a lock to guard the graphics state is insufficient here. If the graphics state is guarded by a lock, common when multiple asynchronous threads are sharing a graphics state, then the signal handler must also honor that lock. This can lead to a contention problem should the signal handler be invoked on the thread already holding the lock. An application becoming unresponsive during app window resizing is an application design problem, and is best addressed at the application level, not as pat of the window server and compositor design. The window server design should provide mechanisms, but strive to be as free of policy as possible. Usability issues such as an unresponsive application are better handled as part of the user interface policy mechanisms, implemented as part of the toolkits and desktop management logic. The window server can provide the mechanisms to move, hide, show, and resize windows. Decisions as to how to handle unresponsive applications and present UI regarding these applications is best done at a higher level. Mike Paquette Just notify the client if it's alive. But if the client is sure to be dead locking in some place (by checking the waiting channel of the client), call it via signal. Since win2k.sys is in the kernel, so windows really does this logic. But, if wayland is going to use client-side decoration, then we should think more carefully, because we got zero help from the kernel side. Even so , client side decoration is still better than server side. Peng, client side decoration != client side window management. Sorry. I don't understand how to use signals to resolve those kind of problems. When an application is locked, it is very likely with memory corruption too. I think libwayland should be a user space library. Its memory is not protected system, and it may be corrupted too. To resolve this problem, you have to find a way to protect the memory used by wayland library. As I know, only two solutions, putting code in kernel or in a separated process. Peng ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
2011/5/6 Kristian Høgsberg k...@bitplanet.net On Fri, May 6, 2011 at 2:50 PM, Peng Huang shawn.p.hu...@gmail.com wrote: I still remember some old windows systems which use client side decoration. When applications have some problems, you can not use close button to close them. Any the whole decoration will not be repainted anymore, just leave users the background color. That is a really bad UX. I think server side decoration is a better solution. At same time, wayland should allow an application to disable it, and draw its decoration by self. Peng Listen, this is not OK. You're welcome to contribute to the discussion, but I ask that you at least read the other emails in the thread. I'm not asking you to go read documentation or even code, just fucking read what other people have already suggested in the thread, before blabbering out with your preconceived notion of what client side decorations might be. You obviously haven't read the previous mails in this thread or even understand just the basics about how Wayland works. You're replying with a sad anecdote about how you once used a windows system and couldn't close the window and the application didn't repaint. I'm sure that was traumatizing, but it's not relevant to this discussion. You're not helping anybody here, you're just spreading misinformation. I could suggest that you go back and read my suggestions, but that's probably too much too ask, so I'll repeat them here: - the client can specify a rectangle (typically the title bar) where the should interpret click-and-drag as a window move operation. This lets the compositor move unresponsive windows around and is similar to what Mike Paquette described. - the client can specify another kind of rectangle (typically the close button), where the compositor should expect a certain response (window going away, for example) within a few seconds or so. This will let the compositor pop up a Window didn't respond, force quit? dialog either immediately or on the second click attempt. - unresponsive windows wont go blank, the compositor has the contents of the window and can repaint from that. The window contents will stop updating, but the compositor doesn't rely on the apps being responsive to repaint the screen. This is a key feature of composited window systems. I am sorry if I said something wrong. I know some basic theory of compositor. But I still have concern about client window decorations. I think it is very likely an application becomes unresponsive during resizing. Or a user tires to resize a unresponsive window. In that case, I don't know if compositor can draw an updated title bar or just stretch the outdated window context to the new size. At same time how the compositor calculate rectangles' size and position for title bar and buttons? Peng This was a flame. I don't do that often, but I'm fed up with all the uninformed me-too that always happens in all the client-side-decoration threads. Have a good weekend, Kristian On Fri, May 6, 2011 at 1:32 PM, Bill Spitzak spit...@gmail.com wrote: Sam Spilsbury wrote: Actually, I'm pretty sure in 99% of the cases out there the amount of code required for individual applications to have a window border using decorations done on the window manager side is going to be pretty much nil. Size? Resize rules? Name? Icon name? Icon? Layer? Window group? Parent Window? Window role? Desktop? Hardly nil. Take a look at how many pages of stuff is in the freedesktop.org window manager hints. I really don't think this is an issue to do with client side decorations. If the window management policy can't handle the Gimp case correctly, then we need to revise our window management policy, where of course I'm open to ideas here. Window management policy should also be client-side. I may not have been clear about that. The wayland compositer almost NEVER moves or raises or resizes a window. Clients do this in response to clicks or whatever. This would have made it TRIVIAL to implement Gimp the way they intended, as at no time would an image window raise above their toolbars, since they control both of them. I think it is disgusting that for 30 years now we have been forced to not use overlapping windows, primarily due to the idiotic idea that the system should implement click to top (especially idiotic because of the incredible triviality of making the client do that). Every major application (including Gimp...) has been forced to use a single window with a tiled interior, and perhaps some pop-up child windows, because of this bug and am really really hoping Wayland will finally fix it. To handle locked windows the compositor certainly can move, raise, lower and unmap them. It can do this if the user holds down certain keys, or if it detects the application is locked up, or if the user picks menu items
Re: client side decorations
I still remember some old windows systems which use client side decoration. When applications have some problems, you can not use close button to close them. Any the whole decoration will not be repainted anymore, just leave users the background color. That is a really bad UX. I think server side decoration is a better solution. At same time, wayland should allow an application to disable it, and draw its decoration by self. Peng On Fri, May 6, 2011 at 1:32 PM, Bill Spitzak spit...@gmail.com wrote: Sam Spilsbury wrote: Actually, I'm pretty sure in 99% of the cases out there the amount of code required for individual applications to have a window border using decorations done on the window manager side is going to be pretty much nil. Size? Resize rules? Name? Icon name? Icon? Layer? Window group? Parent Window? Window role? Desktop? Hardly nil. Take a look at how many pages of stuff is in the freedesktop.org window manager hints. I really don't think this is an issue to do with client side decorations. If the window management policy can't handle the Gimp case correctly, then we need to revise our window management policy, where of course I'm open to ideas here. Window management policy should also be client-side. I may not have been clear about that. The wayland compositer almost NEVER moves or raises or resizes a window. Clients do this in response to clicks or whatever. This would have made it TRIVIAL to implement Gimp the way they intended, as at no time would an image window raise above their toolbars, since they control both of them. I think it is disgusting that for 30 years now we have been forced to not use overlapping windows, primarily due to the idiotic idea that the system should implement click to top (especially idiotic because of the incredible triviality of making the client do that). Every major application (including Gimp...) has been forced to use a single window with a tiled interior, and perhaps some pop-up child windows, because of this bug and am really really hoping Wayland will finally fix it. To handle locked windows the compositor certainly can move, raise, lower and unmap them. It can do this if the user holds down certain keys, or if it detects the application is locked up, or if the user picks menu items. On windows all we see is that applications can draw widgets inside the existing window border style. This works well in every case I've seen it - chromium, firefox, office, you name it. No on Windows an application can add drawings to the title bar. It is pretty clear that applications are assuming the default Vista colors and button sizes and layouts when making these drawings, thus defeating theming. We still have the problem of not having a universal toolkit to handle these things, and the reality of the matter is that a lot of proprietary applications are not going to want to use these toolkits. I have no idea why you think that making the window borders match is all that is needed. What about the buttons and menus and toolbars and scroll bars and how editing is done? If this is important I would much rather see a solution that addresses all of these, rather than somehow saying the window borders are special. You cannot assume that there will be a universally adopted method to styling because we see on every single platform that there will *not* be one. The best way to enforce styling is to enforce it at the window manager level, so that the applications on the system actually obey what the user wants them to do, not some crazy idea that the application developer had. And this is true on X and Windows today. People bypass the system and draw their own window borders. And the result is far worse than if the system was designed for this from the start. Lets not repeat these mistakes. ___ 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
