From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Touchscreen support Date: Fri, 14 Jan 2022 19:17:38 -0500 Message-ID: References: <87czlxkntg.fsf.ref@yahoo.com> <87czlxkntg.fsf@yahoo.com> <87mtkziwhi.fsf@yahoo.com> <87wnk3h0hn.fsf@yahoo.com> <87o85fgx4x.fsf@yahoo.com> <8735mqh5tp.fsf@yahoo.com> <875yrj3m84.fsf@yahoo.com> <87ilviy3pv.fsf@yahoo.com> <87tuf1s16t.fsf@yahoo.com> <875yrglyid.fsf@yahoo.com> <87sfug557u.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000df1bc305d593d913" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39139"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Lars Ingebrigtsen , Stefan Monnier , EMACS development team To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 15 01:18:52 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 1n8WmS-000A4s-5m for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Jan 2022 01:18:52 +0100 Original-Received: from localhost ([::1]:36424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8WmQ-0004qE-WD for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Jan 2022 19:18:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8Wld-0003nJ-Kh for emacs-devel@gnu.org; Fri, 14 Jan 2022 19:18:01 -0500 Original-Received: from [2a00:1450:4864:20::134] (port=41867 helo=mail-lf1-x134.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8Wlb-0005lE-QO; Fri, 14 Jan 2022 19:18:01 -0500 Original-Received: by mail-lf1-x134.google.com with SMTP id x7so35345297lfu.8; Fri, 14 Jan 2022 16:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A6UlQHFAWt0C2bpTDH9ohKsAxPumI3FI0bH806/rLNU=; b=WOcy1nBM1HUY8d01HQJkLaDUWaVkRWkhZ403YHxxlNMpRu9sBsDeXA0WTgP4sr4l5D VxIUoXUXTuhxNX466bMn1WrYIhy+mSx3GXJ22BINQv5TBRTHbTVE9B4VQDlEzaHr5iC9 ILhgmRWkiuV7wezSXhq603U+hC9GVWTpJwYXkZYmUs2nC9FNpk4Z1IqKphEB4HBCfta0 NcnFy46ebOzxRi2BTFCBI9nT4jc7xCz+/pJKFRs7znvdfT54Gv5O+ZVF8KX01n5Vmjpx M0wk9ugvFA2UDui01dB4ChvjseX9clvVIgZRph5HMdYgc45gGIbIV/MPmd2ww2K33XAf BkIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A6UlQHFAWt0C2bpTDH9ohKsAxPumI3FI0bH806/rLNU=; b=AHkzRfYAKnQVV7fGgzRia3MBRXrVdDDMrVZJHwnnHH+Aez6xEoBNlIfQmCwvgsNe0n t2pyDTYb1+bw7w+qNt5eS0ytKMYLMCusv9pSv5kKJL7DVLUGwLdUCNf3Kgy2yFv9Atsa Cjf2ofhh3c0DGlw2hAM8uuRig0jsiJ4c8oR/R12w5wyqWSFUB3rHZy6lfZUgFJMH7Zas zbzoGf8AXh4KsHRwT/tXl/J+Klz8H8SFFEUgvBdZYOa2rpkFOgCBZI4BJsG5l7GH04x8 FZ2gsW+zOM0a4a1ikp4QlVxhVnQEEOSkNEPml878bWvqTPxPAnN6nHvVAOf3hArnhblY NsvA== X-Gm-Message-State: AOAM530kHqsBoT7jvO3SiL0ip+pkQGa1nTdWWDTj25pyaNQFY2kbMuwN CVUdGMhcfQsl7rRmg+JYE2axMZqsK8qjp57TvsgndsjxZOA= X-Google-Smtp-Source: ABdhPJxt9rGuGuw3KzYyFF9jG1xEczibnSWIl6TXJL5yub6VJCyuv+44uCdQhwhfbHad9EffN04W7o2q9j9G5hX0+io= X-Received: by 2002:a2e:a811:: with SMTP id l17mr8401758ljq.340.1642205875738; Fri, 14 Jan 2022 16:17:55 -0800 (PST) In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::134 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::134; envelope-from=yandros@gmail.com; helo=mail-lf1-x134.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:284762 Archived-At: --000000000000df1bc305d593d913 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 26, 2021 at 11:15 PM Richard Stallman wrote: > > > > Is it to be expected that, at some date, they will say that GTK 3 is > no > > > longer supported and people should downgrade to GTK version 4? > > > If meant "upgrade to GTK version 4", then yes. > > For Emacs, changing to GTK 4 would be a downgrade, so that's what I call > it. > > Anyway, if you're right about their plans, it means that sticking with > GTK 3 is a short-term solution but not a permanent solution. > In general, the currently-used toolkits have raised the floor of the "stamp of approval" abstraction layer. As a (somewhat contrived) example, once upon a time one might have used xmh to read email. It was an X application that used the Athena Widgets and also could use the 3D Athena widgets, so in terms of code, you would see X, XAW, and XA3D calls. These days, one might instead use a GTK4 or QT mail reader, and those toolkits would only "promise support" for code that made gtk or qt calls; the programmer isn't exactly prohibited from using X11 calls, but doing so is not recommended nor supported, and if the programmer runs into trouble, they are very likely to be told "you're breaking the abstraction barrier we set; remove it and then come back with your problem". (This is more or less exactly the situation that created these lines in xterm.c:) #ifdef USE_GTK > /* A long-standing GTK bug prevents proper disconnect handling > . Once, > the resulting Glib error message loop filled a user's disk. > To avoid this, kill Emacs unconditionally on disconnect. */ > shut_down_emacs (0, Qnil); > fprintf (stderr, "%s\n\ > When compiled with GTK, Emacs cannot recover from X disconnects.\n\ > This is a GTK bug: https://gitlab.gnome.org/GNOME/gtk/issues/221\n\ > For details, see etc/PROBLEMS.\n", > error_msg); > emacs_abort (); > #endif /* USE_GTK */ Over time, reaching "past" the abstraction barrier has become harder and harder as the toolkits have become more "all encompassing", to the point where it's more semantically accurate to talk about an app being a GTK or QT (or W32 or mac) app than, say, an X app that uses QT. I don't know if this owes more to "easy platform consistency" or to "just do everything via javascript inside a browser", but the end result is pretty much the same. It probably doesn't help that Wayland is basically a decade old and still doesn't have a stable standard specification (or really a draft spec beyond "whatever is currently in the release code"). Hope that helps, ~Chad --000000000000df1bc305d593d913 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 26, 2021 at 11:15 PM Rich= ard Stallman <rms@gnu.org> wrote:<= br>

=C2=A0 > > Is it to be expected that, at some date, they will say tha= t GTK 3 is no
=C2=A0 > > longer supported and people should downgrade to GTK versio= n 4?

=C2=A0 > If meant "upgrade to GTK version 4", then yes.

For Emacs, changing to GTK 4 would be a downgrade, so that's what I cal= l it.

Anyway, if you're right about their plans, it means that sticking with<= br> GTK 3 is a short-term solution but not a permanent solution.

In general, the currently-used toolkits have raised t= he floor of the "stamp of approval" abstraction layer. As a (some= what contrived) example, once upon a time one might have used xmh to read e= mail. It was an X application that used the Athena Widgets and also could u= se the 3D Athena widgets, so in terms of code, you would see X, XAW, and XA= 3D calls. These days, one might instead use a GTK4 or QT mail reader, and t= hose toolkits would only "promise support" for code that made gtk= or qt calls; the programmer isn't exactly prohibited from using X11 ca= lls, but doing so is not recommended nor supported, and if the programmer r= uns into trouble, they are very likely to be told "you're breaking= the abstraction barrier we set; remove it and then come back with your pro= blem". (This is more or less exactly the situation that created these = lines in xterm.c:)

#ifdef USE_GTK
=C2=A0 =C2=A0 =C2=A0 /* A long-standing GTK= bug prevents proper disconnect handling
<https://gitlab.gnome.org/GNOME/gtk/issues/= 221>.=C2=A0 Once,
the resulting Glib error message loop filled = a user's disk.
To avoid this, kill Emacs unconditionally on discon= nect. =C2=A0*/
=C2=A0 =C2=A0 =C2=A0 shut_down_emacs (0, Qnil);
=C2=A0= =C2=A0 =C2=A0 fprintf (stderr, "%s\n\
When compiled with GTK, Emac= s cannot recover from X disconnects.\n\
This is a GTK bug: https://gitlab.gnome.org/GN= OME/gtk/issues/221\n\
For details, see etc/PROBLEMS.\n",
= =C2=A0 =C2=A0 =C2=A0 error_msg);
=C2=A0 =C2=A0 =C2=A0 emacs_abort ();#endif /* USE_GTK */
=C2=A0
Over time, reaching= "past" the abstraction barrier has become harder and harder as t= he toolkits have become more "all encompassing", to the point whe= re it's more semantically accurate to talk about an app being a GTK or = QT (or W32 or mac) app than, say, an X app that uses QT. I don't know i= f this owes more to "easy platform consistency" or to "just = do everything via javascript inside a browser", but the end result is = pretty much the same. It probably doesn't help that Wayland is basicall= y a decade old and still doesn't have a stable standard specification (= or really a draft spec beyond "whatever is currently in the release co= de").

Hope that helps,
~Chad
<= div>
--000000000000df1bc305d593d913--