Il giorno mer, 14/09/2011 alle 10.37 -0700, Bill Spitzak ha scritto:
>
> Giovanni Campagna wrote:
> > Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
> >> There seems to be some confusion between negotiating the correct size
> >> and the drawing of the frame. These are unrela
Giovanni Campagna wrote:
Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
There seems to be some confusion between negotiating the correct size
and the drawing of the frame. These are unrelated.
I mostly agree with your ideas of negotiating the size with both a
request f
Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
> There seems to be some confusion between negotiating the correct size
> and the drawing of the frame. These are unrelated.
>
> I mostly agree with your ideas of negotiating the size with both a
> request from the client->comp
There seems to be some confusion between negotiating the correct size
and the drawing of the frame. These are unrelated.
I mostly agree with your ideas of negotiating the size with both a
request from the client->compositor as well as the other way, except
there must not be any "looping". The
Il giorno ven, 09/09/2011 alle 10.55 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
>
> > Anyway, I'm not convinced that client-side decorations are technically
> > superior, therefore I'll start a new thread, to have a final discussion
> > with all interested parties. Mutter makes som
Giovanni Campagna wrote:
Anyway, I'm not convinced that client-side decorations are technically
superior, therefore I'll start a new thread, to have a final discussion
with all interested parties. Mutter makes some deep assumptions on
framing, for sizing policies and for event handling, and I'd
Il giorno gio, 08/09/2011 alle 16.55 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
>
> > Yes, but in the middle of this is policy. If the originator of a resize
> > is not the user, how the application can know that the new size is good?
> > We need some way for central policy to kick
Il giorno ven, 09/09/2011 alle 09.30 +0200, Benjamin Franzke ha scritto:
> 2011/9/9 Giovanni Campagna :
> > Il giorno gio, 08/09/2011 alle 17.36 -0400, Matthias Clasen ha scritto:
> >> On Thu, 2011-09-08 at 22:35 +0200, Giovanni Campagna wrote:
> >>
> >> >
> >> > Probably I forgot to mention, but a
2011/9/9 Giovanni Campagna :
> Il giorno gio, 08/09/2011 alle 17.36 -0400, Matthias Clasen ha scritto:
>> On Thu, 2011-09-08 at 22:35 +0200, Giovanni Campagna wrote:
>>
>> >
>> > Probably I forgot to mention, but at the Desktop Summit it was agreed
>> > that client-side decorations won't happen, ne
Giovanni Campagna wrote:
Yes, but in the middle of this is policy. If the originator of a resize
is not the user, how the application can know that the new size is good?
We need some way for central policy to kick in, and that's what I'm
asking for with the explicit "configure" request. All the
Il giorno gio, 08/09/2011 alle 17.36 -0400, Matthias Clasen ha scritto:
> On Thu, 2011-09-08 at 22:35 +0200, Giovanni Campagna wrote:
>
> >
> > Probably I forgot to mention, but at the Desktop Summit it was agreed
> > that client-side decorations won't happen, neither in KWin nor Mutter,
> > so t
On Thu, 2011-09-08 at 22:35 +0200, Giovanni Campagna wrote:
>
> Probably I forgot to mention, but at the Desktop Summit it was agreed
> that client-side decorations won't happen, neither in KWin nor Mutter,
> so the client does not need to worry about what edges it should draw.
I think it is tim
Il giorno gio, 08/09/2011 alle 16.32 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/8 Giovanni Campagna :
>>[...]
>>
> > I have nothing
> > against having GDK calling wl_egl_window_resize,
> > cairo_gl_surface_set_size, cogl_onscreen_update_size, etc. as part of
> > interactive resizing, and I have
Il giorno gio, 08/09/2011 alle 12.45 -0700, Bill Spitzak ha scritto:
> Kristian Høgsberg wrote:
>
> >> You want a concrete example? Consider edge tiling: in that mode, the
> >> window is not resizable, and attempts to programmatically resize it
> >> should be cached and reapplied when the window i
2011/9/8 Giovanni Campagna :
> Il giorno gio, 08/09/2011 alle 14.31 -0400, Kristian Høgsberg ha
> scritto:
>> 2011/9/7 Giovanni Campagna :
>> > [...]
>> >
>> > You say it: "it's more important that clients always know exactly that
>> > the buffer size of the EGLSurface they're rendering to correspo
Il giorno gio, 08/09/2011 alle 14.31 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/7 Giovanni Campagna :
> > [...]
> >
> > You say it: "it's more important that clients always know exactly that
> > the buffer size of the EGLSurface they're rendering to corresponds to
> > the size of the window". If
Kristian Høgsberg wrote:
You want a concrete example? Consider edge tiling: in that mode, the
window is not resizable, and attempts to programmatically resize it
should be cached and reapplied when the window is desnapped. Shall we
tell the client it is edge tiled? If we go that road, we end up
2011/9/7 Giovanni Campagna :
> Il giorno mer, 07/09/2011 alle 14.07 -0400, Kristian Høgsberg ha
> scritto:
>> 2011/9/7 Giovanni Campagna :
>> > Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
>> > scritto:
>> >> 2011/9/6 Giovanni Campagna :
>> >> > Il giorno mar, 06/09/2011 alle 17
Il giorno mer, 07/09/2011 alle 14.07 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/7 Giovanni Campagna :
> > Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
> > scritto:
>>
>>[...]
>>
> >> Finally, wl_shell is far from complete. It's intended to encapsulate
> >> the interactions d
Il giorno mer, 07/09/2011 alle 16.35 -0400, Kristian Høgsberg ha
scritto:
> On Wed, Sep 7, 2011 at 4:27 PM, Giovanni Campagna
> wrote:
> > Il giorno mer, 07/09/2011 alle 10.33 -0700, Bill Spitzak ha scritto:
> >> In Wayland the client allocates the buffer, not the compositor.
> >>
> >> I think thi
Il giorno mer, 07/09/2011 alle 14.07 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/7 Giovanni Campagna :
> > Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
> > scritto:
> >> 2011/9/6 Giovanni Campagna :
> >> > Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
> >> >
On Wed, Sep 7, 2011 at 4:27 PM, Giovanni Campagna
wrote:
> Il giorno mer, 07/09/2011 alle 10.33 -0700, Bill Spitzak ha scritto:
>> In Wayland the client allocates the buffer, not the compositor.
>>
>> I think this is what is leading to the confusion here. The compositor
>> has no say over how big
Il giorno mer, 07/09/2011 alle 10.33 -0700, Bill Spitzak ha scritto:
> In Wayland the client allocates the buffer, not the compositor.
>
> I think this is what is leading to the confusion here. The compositor
> has no say over how big the buffer is. Instead the client controls it
> and tells the
I just thought I'd chime in with a little background information on Quartz.
This is purely informational, to give everyone an idea of how these issues were
handled elsewhere. There are lots of possible solutions and tradeoffs.
I'm just kibitzing. Kristian is driving. :-)
On Sep 7, 2011, at
2011/9/7 Giovanni Campagna :
> Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
> scritto:
>> 2011/9/6 Giovanni Campagna :
>> > Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
>> > scritto:
>> ...
>> >> Maybe you should introduce yourself and what you're working on
In Wayland the client allocates the buffer, not the compositor.
I think this is what is leading to the confusion here. The compositor
has no say over how big the buffer is. Instead the client controls it
and tells the compositor what the resulting size is.
To cause futher confusion there is a
Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/6 Giovanni Campagna :
> > Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
> > scritto:
> ...
> >> Maybe you should introduce yourself and what you're working on before
> >> threatening to break proto
Il giorno mar, 06/09/2011 alle 23.30 -0400, Kristian Høgsberg ha
scritto:
> On Tue, Sep 6, 2011 at 6:39 PM, Giovanni Campagna
> wrote:
> > Il giorno mar, 06/09/2011 alle 15.27 -0700, Bill Spitzak ha scritto:
> >> Giovanni Campagna wrote:
> >>
> >> > You can do instantaneous updates even if the siz
On Tue, Sep 6, 2011 at 6:39 PM, Giovanni Campagna
wrote:
> Il giorno mar, 06/09/2011 alle 15.27 -0700, Bill Spitzak ha scritto:
>> Giovanni Campagna wrote:
>>
>> > You can do instantaneous updates even if the size is determined by the
>> > compositor, rather than the client: you just wait for the
2011/9/6 Giovanni Campagna :
> Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
> scritto:
...
>> Maybe you should introduce yourself and what you're working on before
>> threatening to break protocol? I don't know what you're trying to do.
>
> Right, sorry, I should have done it b
Il giorno mar, 06/09/2011 alle 15.27 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
>
> > You can do instantaneous updates even if the size is determined by the
> > compositor, rather than the client: you just wait for the client to
> > prepare a new buffer before redrawing the window.
Giovanni Campagna wrote:
You can do instantaneous updates even if the size is determined by the
compositor, rather than the client: you just wait for the client to
prepare a new buffer before redrawing the window.
The compositor would have to somehow be prepared for the client to
*never* prod
Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
scritto:
> On Tue, Sep 6, 2011 at 5:19 PM, Giovanni Campagna
> wrote:
> > Il giorno mar, 06/09/2011 alle 13.11 -0700, Bill Spitzak ha scritto:
> >> I believe that unless the client has final say, and an unambiguous
> >> method to for
2011/9/6 Giovanni Campagna :
> Il giorno mar, 06/09/2011 alle 16.37 -0400, Kristian Høgsberg ha
> scritto:
>> On Tue, Sep 6, 2011 at 4:11 PM, Bill Spitzak wrote:
>> > I believe that unless the client has final say, and an unambiguous method
>> > to
>> > force a window to any dimension it wants, t
On Tue, Sep 6, 2011 at 5:19 PM, Giovanni Campagna
wrote:
> Il giorno mar, 06/09/2011 alle 13.11 -0700, Bill Spitzak ha scritto:
>> I believe that unless the client has final say, and an unambiguous
>> method to force a window to any dimension it wants, then Wayland is a
>> failure. Please do not c
Il giorno mar, 06/09/2011 alle 16.37 -0400, Kristian Høgsberg ha
scritto:
> On Tue, Sep 6, 2011 at 4:11 PM, Bill Spitzak wrote:
> > I believe that unless the client has final say, and an unambiguous method to
> > force a window to any dimension it wants, then Wayland is a failure. Please
> > do no
Il giorno mar, 06/09/2011 alle 13.11 -0700, Bill Spitzak ha scritto:
> I believe that unless the client has final say, and an unambiguous
> method to force a window to any dimension it wants, then Wayland is a
> failure. Please do not copy the asynchronous window management of X11!
>
> Here is w
On Tue, Sep 6, 2011 at 4:11 PM, Bill Spitzak wrote:
> I believe that unless the client has final say, and an unambiguous method to
> force a window to any dimension it wants, then Wayland is a failure. Please
> do not copy the asynchronous window management of X11!
Yup, what you describe below is
I believe that unless the client has final say, and an unambiguous
method to force a window to any dimension it wants, then Wayland is a
failure. Please do not copy the asynchronous window management of X11!
Here is what I see:
1. There is a client->compositor call that says "resize this windo
Currently, moving and resizing a window works with two requests (move
and resize), that are only concerned with starting WM operations, and
one event (configure), which is only emitted if the WM itself is
resizing the window, and toolkits are allowed to ignore.
This results, at least in libtoytoolk
40 matches
Mail list logo
