[PATCH weston v2 00/24] Initial Xwayland window positioning, with XWM reordering

Daniel Stone daniel at fooishbar.org
Wed Jan 18 12:17:24 UTC 2017


Hi,

On 18 January 2017 at 12:02, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 17 Jan 2017 15:44:32 +0000
> Daniel Stone <daniel at fooishbar.org> wrote:
>> 'react to geometry changes' makes me a little nervous; is there a way
>> you can see that this can be resequenced or moved such that we don't
>> have the intermediate regression?
>
> I think it could be left even as the last patch in the series. In its
> current point of the series it is needed to make -geometry work, but
> after the _XWAYLAND_ALLOW_COMMITS support -geometry should work also
> without it.

Nod. I'm just keen to avoid intermediate regressions for people who
aren't using -geometry, especially if we don't have an ETA for landing
the _XWAYLAND_ALLOW_COMMITS work.

>> 'schedule repaint from MapRequest' looks OK for the second hunk, but
>> the assert added in the first hunk makes the conditional immediately
>> above it dead code. Oops.
>
> weston_wm_window_create_frame(window) sets window->frame_id, so the
> assert just reminds us that frame_id is now guaranteed to be set.
>
> Suggestions on how to improve it?

Yeah, you are indeed right. Maybe just a comment on the assert noting
that the above call sets it? With that, R-b me and clear to push.

>> With these, we just have the difficult ones left: react to geometry
>> changes, schedule repaint from MapRequest / do not draw decor twice on
>> map, and _XWAYLAND_ALLOW_COMMITS. I don't have the mental bandwidth to
>> deal with those today, but if you're able to gang the easier ones
>> together and push them, that at least makes this series very tractable
>> indeed.
>
> Very much appreciated. After we agree on 'schedule repaint from
> MapRequest' and I push it, I will send a v3 which will be just three
> patches.

Bring on v3! \o/

Cheers,
Daniel


More information about the wayland-devel mailing list