-- 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
this might be a question more for these programs than for this list,
but how can one of these programs handle the full desktop realestate?
wouldn't that itself force the same condition that you have with the
rogram being a single window?
On Tue, Sep 13, 2011 at 11:13 PM, Bill Spitzak
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
If I understand the proposal correctly this shouldn't be a problem. If the
application becomes unresponsive the server has the ability to manage it
(move, resize, raise, lower, possibly hide/show, and an option to kill it)
and it knows if it didn't respond to events.
I do think that there is one
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
I thought the compositor would/could provide decoration. the compositors are
after all their own projects as wayland is a protocol, and if you haven't
noticed, most metacity/emrald themes are just a set of pictures, would it be
bad if the compositor had the ability to handle images from files? i
On Thu, May 5, 2011 at 9:48 AM, microcai micro...@fedoraproject.org wrote:
于 2011年05月05日 22:13, cat 写道:
I thought the compositor would/could provide decoration. the compositors
are
after all their own projects as wayland is a protocol, and if you haven't
noticed, most metacity/emrald
there hasn't been any on the subject but I think that most of the work would
be in kernel space, I think that some of these gpu switching systems use
GPUs from different manufacturers (EX. ATI + Intel), so it is not clear if
every instance of this feature is driver dependant or not. if its not
