Migration guide?

[Gregory Merchan]

On Mon, May 7, 2012 at 9:51 AM, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Sun, May 6, 2012 at 4:30 PM, Gregory Merchan

Thanks for the answers! To answer your questions:

>> 3. X11 famously abided by the rule of determining "mechanism, not
>> policy". Is there a similar rule for Wayland?
>
> To some extent. There's the core part of the protocol that concerns
> surfaces and their content, input events and the outputs.  That's all
> fairly generic and the more policy-like functionality is in wl_shell,
> which is "EWMH for Wayland".  That said, X was policy free largely
> because it had to be.  There were no shared libraries or loadable
> modules to allow for easily reusing the core parts of X or loading a
> WM module into it.  There was only one X server, policy had to be
> out-of-process and the protocol grew a lot of ugly corner cases and
> special purpose requests to support this.  Is there a particular
> reason you're asking?

As I see it, a lot of things were done incorrectly on X, mostly out of
concerns for legacy. The policy-free policy meant you could still do
things another way, maybe at the cost of some compatibility.

For example, client-side frames. Any X client could draw it's own
frame, and some like XMMS notoriously did. By a WM_Sn owner property
or target, or a root window property, a window manager could inform
clients that they should frame their own windows; how could even be
described. Clients could have a property to signal that they
understand the frame-your-own-window policy.

Focus handling and window stacking are also done poorly. Consider
Gtk+'s fallback in the case of no window manager. (Dig in
gdkwindow-x11.c for this.) When Gtk+ sets focus to a window in the
absence of a window manager, it first raises the window, then requests
the input focus (from the server). Because the X server might refuse
to give focus (late timestamp, for example), this could result in a
raised window without focus. Instead the code should try to set the
focus and only raise the window after a FocusIn event.

That's just an example from a code path that rarely sees execution,
but I think it's indicative of the problems elsewhere.


>> 4. I'm concerned about the implications of this message:
>> http://lists.freedesktop.org/archives/wayland-devel/2012-January/001845.html
>> . It looks like policy was being written into Wayland, but maybe that
>> discussion was about Weston?
>
> Click to focus is just a weston thing if that's what you're concerned
> about.  The policy/mechanism line isn't as black and white as it
> sounds - what specifically are you thinking of?

Oh, no. I'm very much in favor of click-to-focus. It's how you do it
that matters to me. As far as I can tell, all the X window managers
and toolkits are broken when it comes to handling that first
ButtonPress on a window. The window managers all have a passive grab
on the button to enable click-to-focus, and they all call
SetInputFocus or send a WM_TAKE_FOCUS message on that ButtonPress.
Raising policy varies I suppose. For the globally active input model,
this is wrong. There's no need for the button grab because the
globally active model indicates (or should indicate) the app will set
focus when it sees the ButtonPress, or not set focus in if it could
start a drag for drag-and-drop. The WM_TAKE_FOCUS message should be
for when the window manager frame is clicked or some alternative focus
method like Alt+Tab or a task bar click is used. That's just my
favorite example. How utility windows (toolboxes, floating panels,
etc.) and focus interact is another.

I was overjoyed to see Mr. Spitzak raise the raising issue. My concern
is that the bad behavior of today's X clients and window managers
might get locked in.

Thanks again for the answers,
Greg