client side decorations

[microcai]

于 2011年05月07日 06:01, cat Wrote
> ---------- Forwarded message ----------
> From: cat <zixon65 at gmail.com>
> Date: 2011/5/6
> Subject: Re: client side decorations
> To: Kristian Høgsberg <krh at bitplanet.net>
> 
> 
> 
> 
> 2011/5/6 Kristian Høgsberg <krh at bitplanet.net>
> 
>> On Fri, May 6, 2011 at 3:14 PM, cat <zixon65 at gmail.com> wrote:
>>>> "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 wouldn't use wayland if thats the case, the kind of security risk this
>>> creates is massive. you could have clients that refuse to cooerate and
>>> always take up the entire screen, or worse, rendering your computer
>> useless.
>>> also I never like muti window apps like the gimp, or openoffice. they
>> draw
>>> your attention away from what your doing to rearrange these little
>> windows,
>>> and what ever you do don't close them or would could spend the next hour
>>> trying to get them back. there sould always be central system for making
>>> windows behave or they won't
>>
>> I don't know what window system you're currently using, but if you're
>> using X, hit Ctrl-Alt-Backspace now, because it has all the same
>> problems.
>>
> 
> that key combination has been disabled in Xorg by default for a while, which
> is extreamly annoying because X runs rather well without a config. also a
> new problem is that programs that lock up like to take focus and the only
> way to recover then is the magic sysrq keys. really I have just gone back to
> using the power button. atleast that still cut off power after 4 seconds.
> 
> 
> And you should go read my reply to Peng, because it applies to you too.
>>
> I like some of the suggestions that have been put forward. but Bill made
> sound as though wayland clients should do everything by themselves. why then
> use the compositor?
> 

I know that, Windows push every windows stuff to client. They had
default toolkit called DefWindowProc.

And now, they  think they made a mistake. Then they are trying to
recover, to do things like compiz.

Client side windows management does not  help much. The windows get help
from the *kernel*, and still can't do things better.

The wayland? We don't have kernel module to help us force the policy to
the client! If the client refuse to cooperate, then everything is gone.

You think windows can do it in client way, so do wayland? NO!
They got help from the kernel! They had something called LPC, so dead
lock app can still run DefWindowProc if the kernel want it response the
message.

As for wayland, we are not so lucky. Think of it, how do you suppose to
close the misbehaved window? To move the dead window?

So, client side window management is wrong  unless you got help from the
kernel side. But client side window decoration is not wrong.

non-uniform looking? EM. they use the toolkit, but the toolkit in return
use libwayland! libwayland can do the drawing. For the sake of app
developers, libwayland drawing is no much different than compositor
drawing.

But, hey, wait a second! In fact , windows do not even have decorations
! decorations is just another sub window created *automatically* when
you call CreateWindowEx . The close button? another subwindow belongs to
the decoration. This way, they simplify the windowing system for not
treating decorations specially.



-------------- 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/d8fb24f4/attachment.pgp>