Re: [PATCH weston 2/2] compositor: set weston_surface:resource to NULL when destroyed

2013-11-18 Thread Bryce W. Harrington
On Fri, Nov 15, 2013 at 10:06:15PM +0100, Giulio Camuffo wrote: > with the previous patch the resource isn't used inside > weston_surface_destroy() > anymore (aside sending events unuseful for a closing client), so we can safely > reset it. > > Reviewed-by: Jason Ekstrand > --- > src/compositor

Re: [PATCH] client: Introduce functions to allocate and marshal proxies atomically

2013-11-18 Thread Bryce W. Harrington
On Fri, Nov 15, 2013 at 08:51:50PM -0800, Kristian Høgsberg wrote: > The server requires clients to only allocate one ID ahead of the previously > highest ID in order to keep the ID range tight. Failure to do so will > make the server close the client connection. However, the way we allocate > ne

Re: [PATCH 1/9] animation, shell: add kbd focus change animation

2013-11-18 Thread Bryce W. Harrington
On Fri, Nov 15, 2013 at 05:53:30PM +0100, Emilio Pozuelo Monfort wrote: > From: Louis-Francis Ratté-Boulianne > > When enabled, this will make all but the keyboard-focused window dim. > Also the background gets dimmed, if there are any windows open. The > panel is not dimmed. > > When the keyboa

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Bill Spitzak
Thiago Macieira wrote: The only detail is that this extension doesn't exist yet, so the compositor needs to check whether the client acknowledged the message. If it didn't, then the compositor must assume the client is decorating itself. I think it will be ok for the compositor to assume it w

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Bill Spitzak
Thiago Macieira wrote: On segunda-feira, 18 de novembro de 2013 10:28:12, Bill Spitzak wrote: Can you explain why "consistency" is so important for the window frame, but is not a problem for the buttons and scrollbars and text fields and everything else inside the frame? I personally think th

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Bill Spitzak
Neil Roberts wrote: You are advocating requiring *both* clients and compositors to be able to draw decorations. Why make it so complicated? No, I didn't say that at all. I am saying that in xdg-shell we need to specify that either CSD is required or SSD is required. Okay, you are now saying

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Jonas Kulla
2013/11/18 Neil Roberts > Thiago Macieira writes: > > > Make it simpler: all clients MUST be able to draw decorations. That's > what > > Wayland up until now requires anyway. > > I think it's a shame to throw out the idea of making the policy be that > clients are allowed to expect SSD if they d

[PATCH] pixman: Check whether the buffer still exists when the surface is redrawn

2013-11-18 Thread Lubomir Rintel
While the pixman image might be attached, the underlying buffer might be already gone under certain circumstances. This is easily reproduced by attempting to resize gnome-terminal on a fbdev backend. A more proper fix (without skipping rendering of the surface) would need a change to Wayland API,

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Thiago Macieira
On segunda-feira, 18 de novembro de 2013 10:35:58, Bill Spitzak wrote: > I also want to put in a very strong vote against any kind of idea that a > client can "prefer SSD", as is being continuously suggested here with > comments like this: > > Thiago Macieira wrote: > > A client MAY ask the compos

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Thiago Macieira
On segunda-feira, 18 de novembro de 2013 10:31:15, Bill Spitzak wrote: > So here is even simpler: > > - All clients MUST be able to draw decorations > > - The compositor, as part of configure events, can tell the client to > not draw decorations. That also works and it's even simpler. -- Thia

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Thiago Macieira
On segunda-feira, 18 de novembro de 2013 10:28:12, Bill Spitzak wrote: > Can you explain why "consistency" is so important for the window frame, > but is not a problem for the buttons and scrollbars and text fields and > everything else inside the frame? I personally think that it is a problem.

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Neil Roberts
Bill Spitzak writes: > Can you explain why "consistency" is so important for the window > frame, but is not a problem for the buttons and scrollbars and text > fields and everything else inside the frame? In the case of a game there probably wouldn't be any buttons or scrollbars so the only thin

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Bill Spitzak
I also want to put in a very strong vote against any kind of idea that a client can "prefer SSD", as is being continuously suggested here with comments like this: Thiago Macieira wrote: A client MAY ask the compositor to draw decorations. This is going to be used as an excuse by clients to *

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Bill Spitzak
Again this is excessively complicated. The compositor in current weston can already tell the client to not draw decorations. This indicator is combined with the "fullscreen" indicator but the communication is already going this way. So here is even simpler: - All clients MUST be able to draw

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Bill Spitzak
Neil Roberts wrote: I guess you could make a toolkit-agnostic decorations library using subsurfaces that these types of applications can use. However I don't think that will solve the consistency issue because most game-type applications will want to bundle all of their dependencies so they will

Re: [RFC] Object's pre-actions

2013-11-18 Thread Pekka Paalanen
On Mon, 18 Nov 2013 16:54:03 +0100 Marek Ch wrote: > Hi, > > in reaction to > http://lists.freedesktop.org/archives/wayland-devel/2013-November/012018.html > I have got an idea and I like to share it with you and possibly get a > feedback. > > What I was thinking about is: > Add into wl_object

[RFC] Object's pre-actions

2013-11-18 Thread Marek Ch
Hi, in reaction to http://lists.freedesktop.org/archives/wayland-devel/2013-November/012018.html I have got an idea and I like to share it with you and possibly get a feedback. What I was thinking about is: Add into wl_object another variable for listener (implementation) that would be set when p

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Neil Roberts
Thiago Macieira writes: > Make it simpler: all clients MUST be able to draw decorations. That's what > Wayland up until now requires anyway. I think it's a shame to throw out the idea of making the policy be that clients are allowed to expect SSD if they don't want to draw decorations themselve

Fwd: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Cedric BAIL
Hello, On Fri, Nov 15, 2013 at 12:17 PM, Martin Gräßlin wrote: > this is a reply to the topic of whether to have information about decorations > in the xdg_shell at all (see [1]). Sorry that I don't reply to the right > message, had not been subscribed to the list. > > I want to outline why we in

Re: Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Martin Gräßlin
On Monday 18 November 2013 02:58:41 Jasper St. Pierre wrote: > If the KDE team feels extremely strongly about server-side decorations, I'd > like to see that passion channeled into actually building things. Write an > extension that does what you want. Patch weston/westoy and KWin/Qt to > implement

Re: Thoughts about decoration information in the xdg_shell

2013-11-18 Thread Thiago Macieira
On segunda-feira, 18 de novembro de 2013 08:36:48, Martin Gräßlin wrote: > Such a protocol would make runtime switching impossible, wouldn't it? "Now you draw, now I draw" ? Yes. > That's a really important use case for us to turn a tablet into a desktop > and vice versa. I don't think so. You