The road to Wayland/Weston 1.6 and 1.5.1

[Jasper St. Pierre]

On Mon, Aug 18, 2014 at 12:55 PM, Bill Spitzak <spitzak at gmail.com> wrote:

>
>
> On 08/18/2014 04:35 AM, Pekka Paalanen wrote:
>
>  Obviously a stable first version of xdg_shell would be great to see in
>> 1.6, but we shall see if we can beat it into shape in time. When I
>> reviewed the XML spec not long ago, it was close but not ready in my
>> opinion.
>>
>> When xdg_shell does stabilize, we will move xdg_shell.xml into Wayland
>> repository and it will be installed,
>>
>
> I know I am being a pain in the ass about this, but I don't think
> xdg_shell can be considered stabilized until there is an active request the
> client *must* do to raise a surface in response to a mouse click. If the
> current api is "stable" then in the future a request is going to have to be
> added to disable automatic raise. This will result in three apis to the
> default shell (wl_shell, xdg_shell with auto-raise, and xdg_shell without
> auto-raise), as well as adding a request that is obviously a
> back-compatibility hack and that all toolkits will just have to do
> immediately after creating each xdg_shell.
>

I will be completely honest here. I don't give a shit about apps
controlling raise-on-click behavior. This is not a problem I care to solve.
WM policy dictates whether the window should raise on click, much like it
always has under X11. Nothing in the xdg-shell protocol says that when
clicking on a surface, it is raised above other surfaces.

That said, it is entirely possible to add a future request which can
disable the WM "raise on click" behavior in the future, going to an
explicit raise mode if you want, for the two clients that will use such a
feature. It will not be three separate APIs, it will be an additional mode
to the existing API. It will not be a big burden on my part to implement in
the compositor. I do not want to burden the rest of the apps that do not
care. I am not sure how this interacts with focus-follows-mouse and other
sorts of stacking order, but a compositor can just pick a sane policy and
live with it, I guess.

Should we make libinput the default for 1.6, so that in 1.7 we can
>> remove the old input code, or is libinput API still too much in flux?
>>
>
> Changes in the libinput api don't sound like they would be a problem,
> because both weston and libinput are updated at the same time. I suppose if
> somebody writes another compositor they may be bothered by libinput
> changing but that is already true.
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140818/de18c64b/attachment.html>