client side decorations
microcai at fedoraproject.org
Sat May 7 08:40:10 PDT 2011
于 2011年05月07日 19:47, Peng Huang 写道:
> 2011/5/6 Kristian Høgsberg <krh at bitplanet.net>
>> On Fri, May 6, 2011 at 2:50 PM, Peng Huang <shawn.p.huang at gmail.com>
>>> I still remember some old windows systems which use client side
>>> When applications have some problems, you can not use close button to
>>> 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,
>>> should allow an application to disable it, and draw its decoration by
>> 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?
Like I said, the compositor can call the client unconditional via
signal. No matter it is live or dead lock.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel