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 14:51:48 +0300 Message-ID: <83sfln89ez.fsf@gnu.org> References: <875yillm64.fsf@gnus.org> <87edx9ist0.fsf@yahoo.com> <874jy5gjoi.fsf@yahoo.com> <87wnb0bnmn.fsf@gnus.org> <87tu64ec1w.fsf@yahoo.com> <875yik8pb6.fsf@gnus.org> <87bksceaqu.fsf@yahoo.com> <87czcs79l8.fsf@gnus.org> <87wnb0ctf0.fsf@yahoo.com> <87y1vf8rto.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 13:53:41 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 1oQSTU-0007o9-W2 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 13:53:41 +0200 Original-Received: from localhost ([::1]:44494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQSTU-0004uj-2D for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 07:53:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49042) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQSRj-0003eH-2Y for emacs-devel@gnu.org; Tue, 23 Aug 2022 07:51:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42138) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQSRi-0004dd-CY; Tue, 23 Aug 2022 07:51:50 -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=yTRzmUJK8dUrJY5sC4maOdpXpXOoUQnh8kPgJrkz5S8=; b=b4vdGVtVQrYh PkJNespLEPia51r7ttsyOd9u54ycK/4tIh5xSHe2LJXij8BwBdFysjfbtIdT5AUimY4tImZaxPMFJ eTqWdCuwe/uXxMtYdJgNJ8LLjGr8ZBHJVRABa39QlXiL9Qp4/iXpPrIGna3p1iYWSVapYW7ocM6Lz DqyDufYQ1Y7XzxnwZOuJgJtKoFW8ifPyBVeTbbr6cS/a3ElwuB9uSemmxwk79KmiSMFW48lWBETBY RzO4fBSW/sVH2+qOWWe/CTcOtvO5aXGhT5oeu6UOvCZnlIj/wZpUubR9QOlf2hQQHh6sxiftMlBjf lG4yyLRkfapNl4Zm0WeV0A==; Original-Received: from [87.69.77.57] (port=1271 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 1oQSRa-0004Wq-NV; Tue, 23 Aug 2022 07:51:46 -0400 In-Reply-To: <87y1vf8rto.fsf@yahoo.com> (message from Po Lu on Tue, 23 Aug 2022 13:14:11 +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:293868 Archived-At: > From: Po Lu > Cc: Gregory Heytings , emacs-devel@gnu.org > Date: Tue, 23 Aug 2022 13:14:11 +0800 > > But after some investigation, I've come to the conclusion that no > toolkit will be able to replace the hand-crafted Emacs X11 support, > especially in very tricky areas such as drag-and-drop and selections. I question the validity of such a radical conclusion. I think it is asking for too much, something that is not really necessary in this case. > For example, Qt doesn't respect kDNDStatusSendHereFlag in XDND > drag-and-drop messages, fails to wait for XdndStatus before sending > XdndPosition/XdndDrop, and provides no method for programs to set it on > their drop targets. It also doesn't support the X Direct Save protocol, > which can't be implemented on top, since the special action required for > it is abstracted away and not available to programs using Emacs, or the > the Motif and OffiX drag-and-drop protocols. All of that is tolerated > by other programs but will lead to problems over slow network > connections. I think this is still better than the situation with GTK. So yes, we need to give up something, but if someone wants a nice toolkit appearance and widgets that look reasonably modern (something that we will never have in the non-toolkit build), they might just agree to the tradeoff. After all, no one will convince me that DND is the most important operation in Emacs, not even that it is important. It's a nicety, that's all. > And it probably won't be possible to step through a selection converter > with Edebug, or to install our own selection converter when Qt > misencodes COMPOUND_TEXT. Doesn't Qt provide support for non-text selections OOTB? If it does, why would we need to step through the converted? Again, we shouldn't require a perfect toolkit, we should settle for a reasonably good one. Because none of the alternatives is such a perfect choice.