Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 20:18:16 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> > And then we have display of images, which again uses platform-dependent
> > GUI API calls, mouse and keyboard inputs and WM events that are
> > accessed using platform-dependent GUI API calls, etc.
> 
> They are platform calls, a GUI toolkit need not be a middleman. Our GUI
> elements here can be thought of as one of those images, as an example.

Not necessarily.  On some platforms, the "toolkit" is built-in: you
cannot display a GUI window without using the toolkit.  MS-Windows is
one such platform (and I believe NS is another).

> We simply tell system's window/frame to display it, like BitBlt or
> StretchDIBits fron Win32 API.  Same for input.

That doesn't really work.  For example, the pixels that you want to
bitblt have to be created somehow, and how do you think you create
them, if not by drawing to some off-screen surface using those same
GUI API calls that you want to avoid.  (Assuming, that is, that you
don't really intend Emacs to construct those pixels bit by bit "by
hand", i.e. reinvent all the graphics programming from scratch.)

> > Of course, we do.  Displaying text in a GUI window (a.k.a. "frame")
> > requires Xlib calls on X, Win32 API calls on MS-Windows, etc.  And the
> > fonts available on each platform OOTB are generally different.
> 
> These are also simply platform layer calls right?  There's no widget toolkit
> involved.

Not necessarily.  For example, menus on Windows cannot be created
without going through the "toolkit".

> If a platform does not provide text rendering, we could use
> something like FreeType, which is what Xft uses I presume?

AFAIR, FreeType port for Windows calls Windows APIs where it needs to
access system services.