From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Abysmal state of GTK build Date: Wed, 24 Aug 2022 11:23:10 +0800 Message-ID: <87lere495t.fsf@yahoo.com> References: <8735dn30if.fsf@gmail.com> <87pmgr8m3t.fsf@yahoo.com> <83pmgr88sk.fsf@gnu.org> <87sfln6t3p.fsf@yahoo.com> <83ilmj873l.fsf@gnu.org> <8735dn6rp7.fsf@yahoo.com> <87edx7hu15.fsf@telefonica.net> <87edx65sol.fsf@yahoo.com> <87fshmgyng.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34125"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 24 05:24:09 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQgzv-0008kd-UF for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Aug 2022 05:24:08 +0200 Original-Received: from localhost ([::1]:54722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQgzu-0004kn-Am for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 23:24:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQgzH-000446-Jk for emacs-devel@gnu.org; Tue, 23 Aug 2022 23:23:27 -0400 Original-Received: from sonic304-20.consmr.mail.ne1.yahoo.com ([66.163.191.146]:45196) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQgzE-0002pe-9v for emacs-devel@gnu.org; Tue, 23 Aug 2022 23:23:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661311399; bh=DaNAOGegSGvV/9KzPPtF+QKXqUaX83qyfOGhTO8w8JY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=s5DwbM3mU7SQQp1QlEE3alNE3SE3Btjl7UkEJO5P9fwf44RYS6B/P81p0EuAWY2nRZRUZ3NyLtgJZ6HFt1e/OzBPUEIYTR1jL3jnPrzjIjrTOQcZ4NYkmpQycTtdsxUImW0qPmVyJDDQEv/ImLg0SYiX4jRVpK/6zbjbNo3VPb5XklszOrzxlsWbxZXn6+AT1q0mZGwlFldY6OejMYR1UfTNtopUz9UvDa5bYr06+o6srsk9nkxn4FfNsVhjk11so9Y13tZKmvFqEG/0eZteO+wmc++RYyC1GxOG9tm/lhFb9cbpuJvUrRtDXLDal2mCG1R7Ci4T0VZBceydoM0mMA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661311399; bh=81txhAa007Wscda30C26ckgMGPA80kBd2gMURBKXIob=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=HlF8zkCrqpNeqRn0PJ1cCLqgOH0qctPuatShvG1PNtKYY1bEve5w+FSlKk8wEL89DM8y8Bb6zLttfd6xUQnTcR3kC0CJicqJc2Snj5NMgsYDMMXHVs3YOUt43WMfg1YD5elXv1sQPfyo5gnm5OV0rChvkJuybA6BvYOjBc3C+5U5nYB412RNy/PFlCtlTrcI+fbXjH59LMV4bh+ZpKtUIcQB6yBL82NHGETD8aJCWcPiJce89k5c4NdbUqnfq9l0JMBeI38Xw7hgMoiFeWowHV+bJ3mI6os1UbTW+7XVRTHUfMmSeB0/GnsF7iPcMRpL00qiksUeDGFw+vMvvmQVEw== X-YMail-OSG: 93NwMYEVM1lWfNKZ2D.Qa4aTtRNA5FVEcY9llQf57AdtT..LoCnI4BUfnJcZ1j2 fbw4c5BJMIQtBlQh3tlJR_p0nt0TJvPXEYJhvIvvVlbINFD9otzmCxzJVkEevv.DYLLbKe8LIX2r tPHUVjOqAAcywBh4YclzXsRwyeEYB1X3XMMFickzUNKnAJYpFLmYs.sbU_SFj.9YRD2oyPjMTifN YuMtXio.PE8pDcTgnghtL6GeQtYOBcjzHwtxpqoDSSoltIIgcPYIOTTxl3nT_sVUuT8_n6dZq4j6 U6nt_2dsvpR7fgN8r95CMAZKO1CMW.zBw1QUcMcTKdu6u59PslhvaERQCVOeGDQejvDn1Jpvskxx n24vSZS4JLzDCIqqe.D98Nn0EetevuMB5Bi4bPS7A7jIyJjym1xy2tnynO5viRxQcD8X8H1EMASR jnfVxTk9N7XDyje.pTW3m1Yq2RbaEVnKWGspx6FNFBP95XV20eYccnTTZgNhPcKW_mKnQm4hp9z2 OTO8Lp3rGZmYLtCJENLUhW1v_jDk8AQs_CO796coiNWgNaQvKq_JgjgOiGozQomLBewsJxpMCyF2 rWwK77Hroar6p_y366lNerAdpHT0R62RXO02m4RHOKqqzxU3IE99cQfsY_l2vvc..zK3AsRtpm0. wyJD_fMM._LdZ5GiTnTm7yf1wNSz3imA_RR4ZlGogPnBOb7GtpuiqoNV8BwErPxveBBynuuxsQ27 4lFmfV7XVOUsJmxKoB2WvBR80Oo6T27LlQnSAeBmPXAfuPtVcbQ_ndZyreezs.vHjWh.6OBja28n yGOWECCmdb9E8XSiJ9ntl.VeubkduxdKzV.CEkl2RN X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Wed, 24 Aug 2022 03:23:19 +0000 Original-Received: by hermes--canary-production-sg3-6f58cd9b5-84qt6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 55677c5ce27e74a4779cc072fb066b59; Wed, 24 Aug 2022 03:23:14 +0000 (UTC) In-Reply-To: <87fshmgyng.fsf@telefonica.net> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Wed, 24 Aug 2022 04:31:47 +0200") X-Mailer: WebService/1.1.20560 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.191.146; envelope-from=luangruo@yahoo.com; helo=sonic304-20.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293934 Archived-At: =C3=93scar Fuentes 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.