I personally does support and only support client side decoration.
Move and resize ? Better be done in the server side.
Average application should never care about where its windows is. The
compositor cares and move them without notify the client.
If the unusual application does care where its
On 11 May 2011 20:25, Bill Spitzak wrote:
> Michal Suchanek wrote:
>
>> Moves and resizes implemented in the client can't work well.
>
> Any resize solution that does not allow an atomic on-screen update of a
> window to it's new size, with the resized decorations and contents, is
> unacceptable.
Michal Suchanek wrote:
I guess there is one thing that can be done. The compositor could
publish a hint to the application that it takes care of decorating the
windows (even if it is a tiling WM and in fact does not but the user
does not want any decorations in the first place)
Indeed this loo
Michal Suchanek wrote:
Moves and resizes implemented in the client can't work well.
Any resize solution that does not allow an atomic on-screen update of a
window to it's new size, with the resized decorations and contents, is
unacceptable. The whole point of Wayland is that the user NEVER s
cat wrote:
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 t
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 t
On 11 May 2011 14:31, Mark Constable wrote:
> On 2011-05-11, Michal Suchanek wrote:
>> Maybe in an ideal world each application would be split
>> into two (or more) processes, one taking care of the UI
>> interaction and the other(s) doing the actual work so
>> that the UI is always responsive.
>>
On 2011-05-11, Michal Suchanek wrote:
> Maybe in an ideal world each application would be split
> into two (or more) processes, one taking care of the UI
> interaction and the other(s) doing the actual work so
> that the UI is always responsive.
>
> However, this is not the case and for moves and
On 11 May 2011 12:05, Russell Shaw wrote:
> On 11/05/11 18:55, Michal Suchanek wrote:
>>
>> On 10 May 2011 05:46, Russell Shaw wrote:
>>>
>>> On 10/05/11 07:29, Daniel wrote:
El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va
escriure:
>
> Though it is possible
On 11/05/11 18:55, Michal Suchanek wrote:
On 10 May 2011 05:46, Russell Shaw wrote:
On 10/05/11 07:29, Daniel wrote:
El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va
escriure:
Though it is possible, I don't like the idea of clients sending hints
about what areas are the close
2011/5/11 Bill Spitzak :
> Kristian Høgsberg wrote:
>
>> I had a quick read through this and there is a lot of overlap with how
>> Wayland works today... are you proposing to change how Wayland works
>> or are you not familiar with what's already in place?
>
> A lot of this is based on my understan
On 6 May 2011 21:14, cat 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 im
On 10 May 2011 04:52, andre.knis...@gmx.de wrote:
> Actually, I think Iskren made a very important point. To take this one step
> further: with CSD, we can't force the client to stop drawing the decoration,
> we can only tell the client that it should. So we can assume Chrome having a
> decoration
On 10 May 2011 05:46, Russell Shaw wrote:
> On 10/05/11 07:29, Daniel wrote:
>>
>> El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va
>> escriure:
>>>
>>> Though it is possible, I don't like the idea of clients sending hints
>>> about what areas are the close box or window border, sin
14 matches
Mail list logo
