client side decorations

[microcai]

于 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>
>> 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
> 

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...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110507/524850a7/attachment.pgp>