From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Abysmal state of GTK build Date: Tue, 23 Aug 2022 15:41:50 +0300 Message-ID: <83ilmj873l.fsf@gnu.org> References: <8735dn30if.fsf@gmail.com> <87pmgr8m3t.fsf@yahoo.com> <83pmgr88sk.fsf@gnu.org> <87sfln6t3p.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6464"; mail-complaints-to="usenet@ciao.gmane.io" Cc: relekarpayas@gmail.com, larsi@gnus.org, gregory@heytings.org, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 23 14:49:30 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 1oQTLV-0001Tp-QH for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 14:49:30 +0200 Original-Received: from localhost ([::1]:52532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQTLU-0003XE-TI for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 08:49:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQTE2-0004st-Iy for emacs-devel@gnu.org; Tue, 23 Aug 2022 08:41:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48376) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQTE1-0006AW-WA; Tue, 23 Aug 2022 08:41:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jREVNnwbDMwrxvkgmckeII0L77IzZc4+fL23g0l9dV0=; b=piyA0X8ANY/Y NCyYAAzfsqxSYJpy27VjL+k674E1oxTyaceg0xxn7Z3Ozr/hrtvpE43s22YWeOqnNTPDA/o0WLfVi I+/LgSrodEuOv2G6rz9l183p0Qm8k1gtmb42pO3ic7BWjSa/7VyKjgNXXiULz3U6JrGofnMMGQJoc niX/5gA775pnptuKWosZk3z/mOtI9Z/vzn5rZmvJtPGA4/O5Qf1BflRaCsMFSfEdRE5coEE2Vn4ru V3J4otSh5eRyT1CBumQ3s3FiS3iVKM1DvF2kZCCzp2AAg14l8UKn3c29WlPE3qWsHdvu9tXZGBmC+ 0Sx71kJvjqQD6Fsu9SCa2g==; Original-Received: from [87.69.77.57] (port=4321 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQTE1-0001zm-8d; Tue, 23 Aug 2022 08:41:45 -0400 In-Reply-To: <87sfln6t3p.fsf@yahoo.com> (message from Po Lu on Tue, 23 Aug 2022 20:29:30 +0800) 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:293877 Archived-At: > From: Po Lu > Cc: relekarpayas@gmail.com, larsi@gnus.org, gregory@heytings.org, > emacs-devel@gnu.org > Date: Tue, 23 Aug 2022 20:29:30 +0800 > > Eli Zaretskii writes: > > > Why is this such a grave problem? E.g., to cancel drag-and-drop, the > > user can drop it onto some place where dropping is a no-op, like some > > window that doesn't accept drops or sometimes at the source from which > > the stuff was dragged. I never had any problems with this. > > [...] > > > Maybe we are again asking too much from the GUI environment, and too > > easily reject environments that are not 110% perfect? If so, it makes > > little sense to do that with Emacs, whose GUI aspects are secondary. > > mouse-drag-and-drop-region cancels the drag and drop operation once the > mouse pointer moves back into a frame that was created by the current > Emacs session, so that more detailed mouse tracking can be used. > > Without that, mouse-drag-and-drop-region is noticably degraded. I disagree. As I said, the user can drop it in some place where dropping is a no-op. And let's not forget that drag-and-drop operation mostly ends in a drop, not in a cancel. Canceling should be much rarer than dropping. > > It is IMNSHO bad policy for a serious project that intends to remain > > alive for many years to put all of its eggs in a single basket. We > > should instead actively seek and try using alternative GUI > > environments, and we shouldn't reject them just because they are not > > perfect. > > We aren't rejecting alternative GUI environments (in fact we are almost > certainly the only program supporting as many as we do), just not making > them the default. I'm not talking about the ones we already support, I'm talking about the future policies of trying to use alternatives to X. It was a response to what you said: > X will probably remain the primary window server for the next decade or > so. I'm saying that we shouldn't stop looking for reasonably good GUI environments because we are complacent with X.