(Not sure if this is the thread to bring this up in.)

Why does Emacs use so many GUI libraries? What is their advantage over
simply creating our own window and drawing our own scroll/menu bar?
Especially considering GUI libraries like GTK are the poster-children of
code-horror? (Which I guess is expected since GNOME people like to spend
their time on this Earth with deeds like slandering RMS. :) )

> Date: Tue, 21 Dec 2021 17:15:26 +0100 (CET)
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> Why does Emacs use so many GUI libraries? What is their advantage over
> simply creating our own window and drawing our own scroll/menu bar?
> Especially considering GUI libraries like GTK are the poster-children of
> code-horror? (Which I guess is expected since GNOME people like to spend
> their time on this Earth with deeds like slandering RMS. :) )

Various people like how various toolkits look and work, and want Emacs
to look and work similarly.  That's all there is to it.

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02025.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 18:48:35 +0200

> Various people like how various toolkits look and work, and want Emacs
> to look and work similarly.  That's all there is to it.

I see, plenitude of choices.  Since my interest is game development It
felt peculiar to me as the common practice there is to just draw your
interface as how you want it to look, make it customizable possibly.

If I wanted to work on something like --with-x-toolkit=no but pretty and
customizable, using simple software rendering to run on all platforms,
is this something desirable?  It could be enabled in early-init to be
used instead of win32 toolkit for example.

> Date: Tue, 21 Dec 2021 18:58:18 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> If I wanted to work on something like --with-x-toolkit=no but pretty and
> customizable, using simple software rendering to run on all platforms,
> is this something desirable?

I don't think I understand what that means in practice.  GUI
programming for drawing is inherently system-dependent; for example,
the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
you explain how something like that can work on all platforms?

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02036.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 20:09:26 +0200

> I don't think I understand what that means in practice.  GUI
> programming for drawing is inherently system-dependent; for example,
> the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
> you explain how something like that can work on all platforms?

For the maintenance of the frame, true, but we do not need the platform
to draw what we put inside that window, no? I still need to use X,
Wayland, win32 etc.  But they need not dictate what the program looks
like, as all video game look different.

> Date: Tue, 21 Dec 2021 19:28:45 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02036.html
> From:	Eli Zaretskii
> Subject: Re: Motif support
> Date:	Tue, 21 Dec 2021 20:09:26 +0200
> 
> > I don't think I understand what that means in practice.  GUI
> > programming for drawing is inherently system-dependent; for example,
> > the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
> > you explain how something like that can work on all platforms?
> 
> For the maintenance of the frame, true, but we do not need the platform
> to draw what we put inside that window, no?

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

> I still need to use X, Wayland, win32 etc.  But they need not
> dictate what the program looks like, as all video game look
> different.

Experience tells us that users on every platforms generally want Emacs
to look and feel like other GUI programs on that platform.

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02040.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 20:37:03 +0200

> 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.
We simply tell system's window/frame to display it, like BitBlt or
StretchDIBits fron Win32 API.  Same for input.

> 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.  If a platform does not provide text rendering, we could use
something like FreeType, which is what Xft uses I presume?

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

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02040.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 20:37:03 +0200

Sorry, forgot to answer the last part:

> Experience tells us that users on every platforms generally want Emacs
> to look and feel like other GUI programs on that platform.

I feels like this contradicts VSCode's popularity, which has it's unique
look?  Why shouldn't Emacs have a signature keewl look?

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02046.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date: Tue, 21 Dec 2021 21:29:55 +0200

> 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.)
> ...
> Not necessarily.  For example, menus on Windows cannot be created
> without going through the "toolkit".

Yes, that is exactly what I meant all along by saying "a simple
software renderer".  It really isn't that hard to draw a 2D GUI, no
need to reinvent all graphics, only a miniscule part. Text rendering
is the hard part, which we delegate. We draw the menus how we want them
to look, then tell the platform to display them.

> Date: Tue, 21 Dec 2021 20:45:07 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> > Experience tells us that users on every platforms generally want Emacs
> > to look and feel like other GUI programs on that platform.
> 
> I feels like this contradicts VSCode's popularity, which has it's unique
> look?  Why shouldn't Emacs have a signature keewl look?

If this is true (I don't use VSCode, so I don't know), then perhaps
because VSCode users and Emacs users have different expectations?

> Yes, that is exactly what I meant all along by saying "a simple
> software renderer".  It really isn't that hard to draw a 2D GUI, no
> need to reinvent all graphics, only a miniscule part. Text rendering
> is the hard part, which we delegate. We draw the menus how we want them
> to look, then tell the platform to display them.

I very much doubt this will produce anything useful, let alone why
would we want yet another "toolkit".  But feel free to prove me wrong
by showing code that does this.

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02048.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date: Tue, 21 Dec 2021 21:51:13 +0200

> If this is true (I don't use VSCode, so I don't know), then perhaps
> because VSCode users and Emacs users have different expectations?

I specifically mentioned that editor because it's popularity became
something ridiculous, almost monopolistic. If we steal even a drop
of that user base Emacs' could double.

> I very much doubt this will produce anything useful, let alone why
> would we want yet another "toolkit". But feel free to prove me wrong
> by showing code that does this.

The code you mention; is it enough for it to be a simple library in a
single C file? Or do you want to see it integrated and working in Emacs?
The latter wouldn't be too easy for me to, if it is not something wanted
in Emacs.  But that could be decided after looking at the former?

> Date: Tue, 21 Dec 2021 21:15:12 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> > I very much doubt this will produce anything useful, let alone why
> > would we want yet another "toolkit". But feel free to prove me wrong
> > by showing code that does this.
> 
> The code you mention; is it enough for it to be a simple library in a
> single C file? Or do you want to see it integrated and working in Emacs?
> The latter wouldn't be too easy for me to, if it is not something wanted
> in Emacs.  But that could be decided after looking at the former?

What would the library be capable of?  You say that you can replace
all the window decorations we now implement via toolkits: menus,
dialogs, scroll bars, title and caption bar, the tool bar.  Will all
of this be in the library, complete with support for colors and other
stuff?  If not, what would such a library prove?

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02051.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date: Tue, 21 Dec 2021 22:23:12 +0200

> What would the library be capable of? You say that you can replace
> all the window decorations we now implement via toolkits: menus,
> dialogs, scroll bars, title and caption bar, the tool bar. Will all
> of this be in the library, complete with support for colors and other
> stuff? If not, what would such a library prove?

Yes, I can do the listed elements (without text; I could use FreeType
but I'd rather keep build simple. And what is the caption bar? I normally
use --without-x), it would look like an Emacs frame with window area being
empty, elements interact-able.  Just rendering code with WinMain.