Re: Abysmal state of GTK build

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> At the pace things are changing, yes.

Sorry, but that's wrong.  6 months is barely enough for a Fedora
release, and definitely not enough for slower-moving GNU/Linux
distributions such as Debian.

> On the original source (*) it was mentioned:
>
>   - Some distributions build Firefox with telemetry disabled, which
>     might significantly skew the results.

"might" doesn't mean "definite".  And it contrasts with my own anecdotal
experience of what people do with GNOME on Wayland.

> I'll add that there are other significant factors, such as age of
> install and release: if you are interested on current trends, you don't
> want to take into account relatively old installs such as LTS, Debian
> Stable, etc., or even a four months old Ubuntu release, you are mostly
> interested on new installs from releases that provides up to date
> Wayland packages and asked the user whether to use Wayland, defaulted to
> it or provided a simple and prominently advertised method for switching
> after the install.
>
> * https://www.phoronix.com/news/Firefox-Wayland-X11-Stats

All I really hear from people is that they install some software, find
out that screencasting does not work, and follow an online guide to log
out and switch to "GNOME on Xorg" instead.

> So compatibility with Gnome is what defines the stability of my KDE
> install? I just care about not experiencing crashes or defects.

No, this is a problem with Wayland in general.  The complete
incompatibility between different compositors.

> See X Developers Conference 2021, the intervention of Matthieu Herb, for
> instance. This is not "people writing on internet blogs."

[...]

> X is considered legacy and, possibly a worse curse nowadays, unsecure.

Sorry, but that only applies if you have no authentication mechanism for
your X server, and have port 6000 exposed to the internet.  Otherwise,
just like under Wayland, programs can only do what their user is
authorized to do.

> For better or worse, new efforts are focused on Wayland. This will have
> dire effects over time on X maintenance.

People can complain all they want, but there are no problems with X due
to those supposedly dire effects.  The difference between X and Wayland
is that X is finished.  There is very little need for maintenance beyond
the occasional build fix, since everything that one could need already
exists, and most rapidly changing components have been devolved out of
the X server (i.e. libinput, DRI/KMS/DRM, et cetera.)

This has already been proven several times.  For example, consider how
adding support for trackpad gestures under Wayland involved a huge
amount of work and bickering over protocol details, while it took only
several hundreds of lines of code in the X server.  Or, consider how
wp_presentation took extremely long to be implemented, and still isn't
available under KWin, while the X Present extension is now available
almost everywhere and is much more flexible (see for example the
target_crtc arg to XPresentRegion, while under Wayland the compositor is
the only program that can determine which output the presentation is
synchronized to, and all compositors I know of simply punt in front of
multiple outputs.)

While under Wayland, problems like screencasting, setting the absolute
position of a toplevel surface, actively grabbing the pointer, or even
warping the pointer, have yet to be solved.  All of this is compounded
by the fact that the reference implementation is not even very good --
for example, it fails to implement constraint adjustments on popups.

> Scaling produces blurriness on XWayland. That's true, its widely
> acknowledged as a problem and people is addressing the issue, slowly.

The problem cannot be addressed correctly due to a fundamental
difference in how scaling works under Wayland and how it works under X.

On X, the X server does not care about scaling.  Everything is done by
the application.  Of course, this does not preclude a mechanism for
making such information known to the compositing manager, such a
_NET_SCALE_FACTOR property that could be put on toplevel windows.

However, on Wayland, the compositor _must_ know about the scale factor
of each buffer committed to a surface, and performs automatic scaling to
the output based on that.  As a result, you can only chose between a
tiny xterm window and correctly scaled LibreOffice, or blurry
everything.

> There is ydotool, which crashes on my system but apparently works for
> others. Just two days ago I found some protocols (one from
> wayland-protocols, the other from plasma-wayland-protocols) that in
> theory allow cursor warping, among other things. I need to figure out
> how to use them.

ydotool is seriously flawed, since it cannot as a matter of principle
know about various things such as the position of toplevel windows.

i.e. how would ydotool implement the equivalent of XKillClient?

> Well, "apt-cache showpkg libgtk2.0-0" shows several hundred dependencies
> on my Debian Testing machine.

They are definitely not important enough to keep GTK+ 2.x there.

In short: Wayland compositors are not ready to become a general
replacement for the X server.  And probably will not in the near future.

That doesn't mean we shouldn't plan ahead, but that we should be
pragmatic and refrain from defaulting to software that is clearly
unready to replace its predecessor and not subject to wide adoption.

And at this point I cannot see what problems Wayland is supposed to
solve, since it is now more fragmented than X was in the 1990s.  The
developers of the reference server are also implementing (unstable, as
usual with Wayland) atrocities such as support for HDCP, which other
compositor developers have thankfully put their foot down on.