[Top][All Lists]

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

Can we go GTK-only?

From: Daniel Colascione
Subject: Can we go GTK-only?
Date: Thu, 27 Oct 2016 12:54:39 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

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.)

reply via email to

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