emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What improvements would be truly useful?


From: Daniel Colascione
Subject: Re: What improvements would be truly useful?
Date: Tue, 6 Mar 2018 09:01:18 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/06/2018 08:52 AM, Eli Zaretskii wrote:
From: Daniele Nicolodi <address@hidden>
Date: Mon, 5 Mar 2018 23:32:28 -0700

I'm far from being familiar with the Emacs codebase thus I may be
reporting something that it is not completely true, however: Emacs was
born as a console only application, the graphical user interface seems
to be duct taped on.

I object to the "duct taped" derogation, and invite you to study the
relevant code before you form your opinions.  Besides, Emacs still
supports text-mode terminals, and moreover, supports text-mode and GUI
frames in the same session (a very important feature), so some degree
of compatibility to a console is still a requirement.

Also, GTK support seems a bit of an hack that
requires layering violations (reaching down to the X primitives) to
work.  Being GTK the only modern toolkit supported on Linux (as far as I
know) and the only way to get nartive Wayland support, some radical
cleanup in that area would probably be a good thing.

It's true that GTK support was added in a not very clean way, but I
don't think we can throw away support for the other toolkits just yet,
because they are still being used.

Eli is right. The current approach is fine, however it got there.

Eventually, we'll have to support Wayland, but I disagree that "radical cleanups" will necessarily be needed. As I wrote a while ago, the right way forward is a pure GTK+ (as opposed to a mixed X11/GTK+) back-end, letting GTK+ handle running on Wayland, and this kind of window system could be most accommodated in the existing model. It'll end up looking a lot like the NS port.

More radical, I think, would be multiple-window-system support. For that, more abstraction in the frame rendering will be required.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]