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: Re: What improvements would be truly useful? Date: Thu, 8 Mar 2018 10:02:16 -0800 Message-ID: <8c827b0f-5864-1b97-4159-4c21fceed341@dancol.org> References: <86578165-1b41-e75c-7180-84d8edefc44b@grinta.net> <83o9k2s4xw.fsf@gnu.org> <65dafef7-3e1f-ba67-6717-c369033533a3@grinta.net> <831sgxrvsq.fsf@gnu.org> <9e3a1c0b-325f-29c6-eb78-dd4b0106e17b@grinta.net> <836067rd97.fsf@gnu.org> <1ba2560c-d23f-e85a-586d-9cf474ec0719@grinta.net> <83zi3jpxpq.fsf@gnu.org> <83ina6puth.fsf@gnu.org> <20180308162433.GA32588@breton.holly.idiocy.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1520532036 17177 195.159.176.226 (8 Mar 2018 18:00:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Mar 2018 18:00:36 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: Philipp Stephani , daniele@grinta.net, emacs-devel@gnu.org To: Alan Third , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 08 19:00:31 2018 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 1etzqA-0004Kd-3r for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 19:00:30 +0100 Original-Received: from localhost ([::1]:40649 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etzsC-0004eR-Kv for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 13:02:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etzs5-0004e1-8w for emacs-devel@gnu.org; Thu, 08 Mar 2018 13:02:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etzs2-0003qD-2q for emacs-devel@gnu.org; Thu, 08 Mar 2018 13:02:29 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:45576) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1etzs1-0003pX-OS; Thu, 08 Mar 2018 13:02:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=VUHjG7xQovjkoNlW+BHd6az8qZjVuZdB7+5DYWjElAI=; b=F8d74ilWReWcFRNoq7TQXMj2sZhfMK9l6BBGRN1QuOeB2XlZcGqKcTobVq+WycEfRbwZznIS7J/X21E6kXlHBFzwNzaUY3nu4lyI9Sv4+gADZQqXUxFWwBSnAB0ZfuLAwqcfnPzGMaoSYlm5ksLyEKXWjE88ViyZafychSn1fUIkmjhp/x+vnTIDExI+SVr9q2QLcpvRXI4L9IkQkLy328cGmE4a80xnxUcx+e8TF+BK8UnARFC4W/LxMC8PQr/AdeNcuCijvIAaNQGkLB2KBgANUjsr/Bq4vKfhyuCPAiP9UN78rJcj3xNacPL+RYejy6yrIqf6p8jGo31QIwQo4Q==; Original-Received: from [172.92.145.124] (helo=[192.168.86.27]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1etzrx-0007Oj-SV; Thu, 08 Mar 2018 10:02:21 -0800 In-Reply-To: <20180308162433.GA32588@breton.holly.idiocy.org> Content-Language: en-US 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:223509 Archived-At: On 03/08/2018 08:24 AM, Alan Third wrote: > On Thu, Mar 08, 2018 at 03:20:58PM +0200, Eli Zaretskii wrote: >>> From: Philipp Stephani >>> Date: Wed, 07 Mar 2018 21:45:46 +0000 >>> Cc: Daniele Nicolodi , emacs-devel@gnu.org >>> >>> By adding a gtkterm.c, that does the same as w32term.c, just for GTK, without referring to X.org in any way? >>> The cleanup would then consist in removing all GTK functionality from xterm.c once gtkterm.c is stable. >> >> (I guess you meant removing GTK-related portions of xfns.c as well?) >> >> If you look at these two files, you will see that the GTK-specific >> snippets in them are a few and far between. Most of the code is >> generic. > > That’s part of the problem with how Emacs deals with GTK, it does many > things the X way rather than the GTK way. > > For example, mouse and keyboard events are dealt with using X code, > but GTK provides it’s own APIs for dealing with them. I thought > implementing touch events would be easy because GTK already does all > the heavy lifting, but Emacs doesn’t use GTK for events. > > I strongly suspect a Wayland compatible GTK Emacs would have to remove > a lot of (all?) X code and replace it with GTK code. > >> My understanding of this sub-thread was that the idea was to separate >> GTK _architecturally_, not just making it yet another display >> back-end. > > I don’t think I understand the difference. Emacs can be compiled with support for many different window systems, such as X11, MS-Windows, and Cocoa/NS. Currently, having chosen the X11 window system, you can go on to choose which toolkit you want to use: Motif, GTK2, GTK3, Lucid, and so on. The proposal is to promote GTK support from an X11 toolkit to a top-level window system, excising, in the process, the GTK display back-end of any mention of X11. I think it's an excellent project and one important to the future maintainability of the project. As much as it saddens* me to say so, X11 is dying, while GTK will continue to be a decent abstraction that will hit the happy, conventional path of GNU/Linux input and display infrastructure. Emacs X11 integration being unusual and dubiously legal has caused compatibility problems in the past, particularly with systems like NX. As part of this effort, I'd love to see more abstraction in the window system selection. All the xterm.c functions that we carefully replicate in every window system really should be a table of frame-specific function pointers, and we should be able to compile a single Emacs binary with support for all window systems enabled simultaneously. * IMHO, Wayland should be been a series of new X protocol extensions, not a greenfield project.