From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Can we go GTK-only? Date: Thu, 27 Oct 2016 12:54:39 -0700 Message-ID: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1477598392 29724 195.159.176.226 (27 Oct 2016 19:59:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Oct 2016 19:59:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 27 21:59:45 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzqpq-0005WI-04 for ged-emacs-devel@m.gmane.org; Thu, 27 Oct 2016 21:59:34 +0200 Original-Received: from localhost ([::1]:44262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzqps-0001al-CR for ged-emacs-devel@m.gmane.org; Thu, 27 Oct 2016 15:59:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzqlF-0006zS-8k for emacs-devel@gnu.org; Thu, 27 Oct 2016 15:54:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzqlB-0001NF-2V for emacs-devel@gnu.org; Thu, 27 Oct 2016 15:54:49 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:35064) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzqlA-0001Mz-Lz for emacs-devel@gnu.org; Thu, 27 Oct 2016 15:54:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=DnCYAVH6mmcP9lSPO/KuPZZk+RXisw3+0/+amJxKa9I=; b=NA8+ouvUYcymQU4eQnCDLtg5KoSkbPkU5d4YlrUnsdBuVB41k0iZOm8olEqk7LS3mkZk3zBzTBJZ9jYZmYGVjJJzn/Y8880nnwhTxybsnOT+RJ9VstRSCw8F4jENqkDFrvlOgLb8iki1SJTmN/etIZfreb0M26h+XytXH4QUx7sTknm0kVqlznOpBQPaJsNtMpyuCctS1PImrpeMn+X17BIQH0c/9KY20VdAN5UmAINKqk9dN+7qWm7lViHQ0TecHdUqziVHrAFl+qyfqPmAcyTw6m+ssLMsetluThfq+Zt3KEaP9gCH79bJPc6Him5EsCbjmSmvwX7j1Zn+/pprZg==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bzql9-0007xL-2R for emacs-devel@gnu.org; Thu, 27 Oct 2016 12:54:43 -0700 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208887 Archived-At: I've been doing some work on xterm.c and friends lately --- it's a very complex subsystem made even more complex by supporting five different toolkits in the same piece of code. GTK support adds a special twist: GTK is nothing like an old-fashioned Xt-style toolkit, and trying to force it into the mold requires going behind GTK's back in ways that are fragile, inefficient, and unsupported. New versions of GTK regularly break Emacs. Emacs cannot take advantage of GTK's support for non-X targets, like Wayland. Do we really need all the legacy infrastructure in xterm? Do many people really build Emacs as a Motif application? The X window subsystem would be made much simpler if we made it GTK3-only. If we did, much of the complexity of the existing code would evaporate, since we'd be using GTK's infrastructure instead of our own. We'd turn Emacs frames into well-behaved GTK widgets --- just run redisplay inside the Emacs-widget's draw method, draw onto the Cairo surface GTK provides. Instead of flushing frames and drawing to the screen directly from input-waiting routines, we'd rely exclusively on dirtying the Emacs widget and letting the GTK's normal Expose-event processing take care of invoking redisplay. We'd have to get rid of the SIGIO input subsystem too, but I think that's a good thing. The size of the xterm codebase would shrink by at least two thirds, I think. We already _have_ Cairo support: sure, it's broken, but the part that's broken is integrating with the horrible Xt hacks, not the drawing itself. As a stepping stone, we should at least remove support for the no-toolkit, Motif, and Athena configurations. (Lucid I can understand.)