Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> That should pretty much guarantee that it will be maintained. But the
> odds of reaching that point are pretty slim, of course, given that we
> don't lack in different viewpoints here.

Maintaining a toolkit, even more so one that supports as many platforms
as we do, is not a one-person job, especially in this rapidly changing
world.

Case in point: Wayland (which we definitely want to support.)

A single expert (or even a small group of experts) will have a very hard
time maintaining a toolkit that will work with Wayland, seeing as you
have to understand XML, a complicated wire protocol and several very
rapidly changing "standard" extensions to do any meaningful work with
it.  For example, an unstable extension is required for a toplevel to
obtain the input focus, and another is required to handle input methods.

Seeing as other programs such as Chromium (and by extension VS-Code) and
even toolkits with ample funding and full-time developers such as Qt
still struggle with Wayland support, I think it would be a very, very
bad idea for us to take that task onto ourselves.

Besides, we will probably not be able to implement everything on other
platforms such as NS, Haiku, or MS-Windows, so such a configuration will
likely be specific to X, which begs the question of why we should use
that configuration instead of the other in-tree X toolkit Lucid.

> I would at least hope that switching to another no-toolkit
> configuration (and removing the current one soon after) is on the
> table. After getting enough consensus, naturally.

You can't really switch "from one no-toolkit configuration" to another,
because they cannot be much different by definition.

My idea of the only remotely practical way to implement a similar
configuration is for everything on the display (such as menu bars and
scroll bars, but not dialog boxes or popup menus) to be drawn by
redisplay through the RIF similarly to how the tool bar is displayed at
present in all platforms except NS and GTK.  I think we can already do
that with the menu bar as well -- the only job that's left is to make it
look nicer, possibly by applying a box and a gray background to the
individual buttons there.

Ideally, this won't require significant changes to the X specific code
at all.

However, exposing that to Lisp would be a bad idea.  If the tab bar
feature is anything to judge by, this seems to be quite difficult and
also tends to create obscure bugs, such as the image relief bugs with
the tab bar.

> It might become feasible to remove a number of them, though. If my
> hunch is right that people have been holding on to no-toolkit, or
> Motif, or Lucid, because they each have some pet bug which is present
> on newer toolkit ports, but not on their chosen one.

People might also have a preference for Lucid or Motif, or even GTK+.
There are also people who want to use Motif/Lucid specific resources, or
GTK stylesheets.

I hope we will not remove any of the toolkit code, no matter what.

> Having a port like that developed could get us +1 such expect.

That assumes someone exists and is willing to do the work.  I don't
think we can magically "have" such a port developed and gain such an
expert.

Would you like to volunteer?