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:45:05 +0300 Message-ID: <83h72386y6.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> <83sfln89ez.fsf@gnu.org> <87czcr6sv4.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5251"; 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 14:57:20 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 1oQTT4-0001AM-NP for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 14:57:18 +0200 Original-Received: from localhost ([::1]:54786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQTT3-0003wz-O1 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 08:57:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQTH9-0008Ei-LK for emacs-devel@gnu.org; Tue, 23 Aug 2022 08:44:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50718) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQTH9-0006lX-8q; Tue, 23 Aug 2022 08:44:59 -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=nnk/uTUr/c2qP77eTKn4G/dauFBr0BS68TfcV+/6hvI=; b=EZYsPwT48fkU 2isalfkI7U9gVvVsPQao/+x3bFfh7F311sCVEXho0YF+vg0r23LQDtxsPirV3IabmPDwFSMLpUlfg /yLLkyLskxRJjX1yLDj64JGL5/+b6Hi+5F8+Euz6C0Ljz0EmzDxNhilrKA+0tStGUbD54hHVUEoHc HkKG0XuDBnFS7wjLcbL+0IsZcrJryPsKwL/yhnLxg4MHrCh6OaW/fNFsacNOtDXTel7Y8fRfhQYQf 3t6T5nFdv/P9YVSpy9nWQNrMvbnjKAnssc2SXRykM+V2BTgTA4jV8VWZ6LI1m9ljGn1Jq/z4zrd+w AboGMZsiJ6aGmZ1ejlsA6g==; Original-Received: from [87.69.77.57] (port=4518 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 1oQTH8-0002FJ-E9; Tue, 23 Aug 2022 08:44:59 -0400 In-Reply-To: <87czcr6sv4.fsf@yahoo.com> (message from Po Lu on Tue, 23 Aug 2022 20:34:39 +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:293880 Archived-At: > From: Po Lu > Cc: larsi@gnus.org, gregory@heytings.org, emacs-devel@gnu.org > Date: Tue, 23 Aug 2022 20:34:39 +0800 > > > 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. > > Well, the point I was trying to make was that we need a toolkit where we > can use the same techniques that we already do to mix Xlib code with > toolkit code, letting the toolkit draw widgets, while allowing Emacs to > handle complicated window system behavior such as drag-and-drop. And my point is that from where I stand, the above is not an absolute, drop-dead requirement. Given the magnitude of the problems and the importance of reasonably good solutions, we should be pragmatic in this, not dogmatic. > > Doesn't Qt provide support for non-text selections OOTB? If it does, > > why would we need to step through the converted? > > COMPOUND_TEXT is an X11 specific text format that Qt doesn't support > correctly out of the box. If that's your problem, I have no problem: COMPOUND_TEXT is a niche capability that I'm surprised people still need these days.