On Wed, Nov 13, 2013 at 01:22:26PM +0100, Jonas Ådahl wrote:
> On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
> wrote:
> > Hi Jonas,
> >
> > On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
> >> Wayland compositors are expected to deal with input device processing
> >> themselves prov
On Tue, Nov 12, 2013 at 08:19:59PM -0500, Jasper St. Pierre wrote:
> Transient windows, at least not as they are today, don't exist in
> xdg_shell. Subsurfaces allow for specially placed surfaces relative
> to a window, so use these instead.
> ---
> clients/window.c | 47 --
On Tue, Nov 12, 2013 at 08:20:00PM -0500, Jasper St. Pierre wrote:
> We want to remove support for these deprecated interfaces. Since
> nothing is using them, this is a simple change.
Applied, thanks.
Kristian
> ---
> clients/window.c | 12
> clients/window.h | 6 --
> 2 files
On Tue, Nov 12, 2013 at 08:19:58PM -0500, Jasper St. Pierre wrote:
> It seems that this was only used by the popup menu infrastructure,
> which can handle this all on its own. Implementing e.g. transients
> in the future can be done with a simple xdg_shell_set_transient_for.
> ---
> clients/image.
On Tue, Nov 12, 2013 at 08:19:58PM -0500, Jasper St. Pierre wrote:
> It seems that this was only used by the popup menu infrastructure,
> which can handle this all on its own. Implementing e.g. transients
> in the future can be done with a simple xdg_shell_set_transient_for.
Yeah, sounds good.
Kr
On Tue, Nov 12, 2013 at 08:19:57PM -0500, Jasper St. Pierre wrote:
> It seems to be the same as window_move, except it ignores the passed
> in serial (???) and instead just uses the one of the display.
Ok, hmm, yes, that's a little odd. Patch committed, thanks.
Kristian
> clients/flower.c
On Wed, Nov 13, 2013 at 03:32:05PM +, Neil Roberts wrote:
> Ok, here is a second version of the patch which leaves the signal
> handler permanently installed and uses thread-local storage to keep
> track of the current pool.
Yeah, that looks good now, both patches pushed.
thanks,
Kristian
>
On Wed, Nov 13, 2013 at 3:41 PM, Bill Spitzak wrote:
> Is this to force the commit so that the subsurface appears? It might be
> better to have a direct way to get the commit to happen without redrawing
> the main surface.
>
It's to make sure that the transient's position and size is set, and th
On Wed, Nov 13, 2013 at 3:36 PM, Bill Spitzak wrote:
> Jasper St. Pierre wrote:
>
> Transient windows, at least not as they are today, don't exist in
>> xdg_shell. Subsurfaces allow for specially placed surfaces relative
>> to a window, so use these instead.
>>
>
> So you noticed that subsurface
On Wed, Nov 13, 2013 at 3:37 PM, Bill Spitzak wrote:
> Did you see my suggestion that the move and resize requests also be merged?
>
Yes, but I don't see what that has to do with this patch. This is about toy
toolkit cleanup...
> Jasper St. Pierre wrote:
>
>> It seems to be the same as window_
Is this to force the commit so that the subsurface appears? It might be
better to have a direct way to get the commit to happen without
redrawing the main surface.
In any case this looks a lot like you are hiding a bug that perhaps
should be investigated, especially if it is in weston or your
Did you see my suggestion that the move and resize requests also be merged?
Jasper St. Pierre wrote:
It seems to be the same as window_move, except it ignores the passed
in serial (???) and instead just uses the one of the display.
___
wayland-devel m
Jasper St. Pierre wrote:
Transient windows, at least not as they are today, don't exist in
xdg_shell. Subsurfaces allow for specially placed surfaces relative
to a window, so use these instead.
So you noticed that subsurfaces and transient windows are very similer,
huh? :-)
In all seriousne
Pekka Paalanen wrote:
Is your whole issue based on the premise, that the output resolution is
not a multiple of output_scale?
I think there is some serious confusion here. Everything here is a
multiple of everything else.
My client is attempting to obey the output_scale on the assumption th
Thanks for the feedback. Here is a version two of the patch which
fixes some merge conflicts on master and adds support for the pixman
renderer.
Kristian wrote:
> As for the pixman renderer it should be a matter of just wrapping
> the calls to pixman_image_composite32() in
> pixman_renderer_read_
Ok, here is a second version of the patch which leaves the signal
handler permanently installed and uses thread-local storage to keep
track of the current pool.
Regards,
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
Linux will let you mmap a region of a fil
On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
wrote:
> Hi Jonas,
>
> On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
>> Wayland compositors are expected to deal with input device processing
>> themselves providing input events according to the Wayland protocol to
>> the clients. So
On Wed, Nov 13, 2013 at 4:00 AM, Christopher James Halse Rogers
wrote:
> On Tue, 2013-11-12 at 22:50 +0100, Jonas Ådahl wrote:
>> Hi,
>>
>> Wayland compositors are expected to deal with input device processing
>> themselves providing input events according to the Wayland protocol to
>> the clients
On Wed, Nov 13, 2013 at 1:49 AM, Kristian Høgsberg wrote:
> On Tue, Nov 12, 2013 at 1:50 PM, Jonas Ådahl wrote:
>> Hi,
>>
>> Wayland compositors are expected to deal with input device processing
>> themselves providing input events according to the Wayland protocol to
>> the clients. So far only
On ons, 2013-11-13 at 11:54 +0200, Pekka Paalanen wrote:
> On Tue, 12 Nov 2013 16:14:36 -0800
> Bill Spitzak wrote:
>
> > Pekka Paalanen wrote:
> >
> > >> The source rectangle *must* be in buffer pixels. Putting it in
> > >> buffer_scale units makes absolutely no sense, as the buffer_scale is i
On Tue, 12 Nov 2013 16:14:36 -0800
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> >> The source rectangle *must* be in buffer pixels. Putting it in
> >> buffer_scale units makes absolutely no sense, as the buffer_scale is in
> >> effect ignored for this surface, overridden entirely by the sca
On 12/11/13 19:28, Emilio Pozuelo Monfort wrote:
> If a view which has focus is destroyed, we would send a leave
> event while changing focus, causing a segfault. Prevent this
> by listening to the view's destroy signal and removing it from
> the pointer focus.
>
> Signed-off-by: Emilio Pozuelo Mo
22 matches
Mail list logo
