Re: SDL terminal type
Po Lu <[email protected]>
| Newsgroups | gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
"Lina Bhaile" <[email protected]> writes: > On Sat, 22 Aug 2026, at 08:00, Po Lu wrote: >> GTK has already proved to have no promise as a long-term expedient for >> supporting Wayland, and I suggest pursuing a terminal backend using the >> Wayland APIs directly instead. I have always intended to do so, but >> there is a project at work preventing me from improving Emacs on Unix >> systems. Moreover, SDL generally supports keyboard input, input >> devices, and input method editors poorly, as was discovered by Luanti >> when they adopted it: >> >> https://github.com/luanti-org/luanti/issues/14545 >> >> And at least one of these modalities is the prop and stay of Emacs, >> limitations in which are much less acceptable here than in a video game. >> (GTK 3.x itself has a similar problem preventing `C-S-u' and `C->' from >> registering which has been reported repeatedly.) > > I'm really pleased to hear that you've considered this as I highly > appreciate your work on the Android and Haiku support. Though I don't > mean to pressure you, I'd argue that some form of accelerated > rendering to Wayland is a high priority for Emacs. I 100% agree, but this neither requires SDL nor is a consequence of vector graphics or using window system's raster graphics library for rendering as such (for example, X servers accelerate all graphics operations performed by Emacs when possible, i.e. on practically all modern systems). > I have wondered if it's possible to pick and choose between parts of > SDL that Emacs can use and parts that are unsuitable. For example, if > SDL_render could be used to draw the terminal area, and other widgets > like menus and toolbars be left to i.e GTK3 (notwithstanding that, as > you mention, GTK is moving away from the kind of immediate-mode > processing that Emacs needs). In this case visual consistency between > Emacs and the desktop environment is retained and having to write a > OpenGL or Vulkan or whatever renderer from scratch could be > avoided. If it turns out that SDL_render needs SDL's event loop I > understand if it'd be too much fuss. Please do let's leave GTK out of any future windowing arrangements for Emacs :-) > I am extremely unemployed at present and I am pretty eager to use > graphical Emacs on my computer again, so if you have an outline of > what is needed I can work on this, unless you'd wish to start it > yourself. I should warn though that I do not have much experience in > working on such a large feature. I am loath to run an LLM on Emacs's > source to have it figure out the details of the internal terminal > APIs, so I'd suggest that some form of internal documentation on the > terminal code, based off the newer backends like nextstep, Android and > Haiku, would be very helpful for porting Emacs to another window > system. It wouldn't be necessary to use any toolkit in order to obtain window decorations, which is really all that SDL provides on Wayland. Instead it would be sufficient to link to: https://gitlab.freedesktop.org/libdecor/libdecor It is the same standard interface for window decorations on Wayland which is used by SDL. It would also be possible to port the oldXMenu library to Wayland, used on X when no toolkit is enabled, or to provide something like to it there, inasmuch as this has already been achieved for MS-DOS. This would also be sufficient to satisfy Emacs's requirements.