Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, and we have to fix bug#56869 by working around the problem, as we
> do with all OS/library-related issues.  Just because it's something else
> that's "wrong" doesn't mean we can ignore the issue.

We cannot work around the problem because it is a NULL-pointer
dereference in GTK, caused by it mishandling several events
consecutively.

In general, Emacs can only prevent GTK from handling certain events.  If
it handles an event that it must handle (in this case,
XI_HierarchyChange) incorrectly, and that causes GTK to later
dereference NULL, there is nothing that Emacs can do.  Just like what
happens when GTK calls _exit under our nose.

> Anyway, I'm all in favour of defaulting to a no-toolkit build (across
> all systems -- the astounding success of VS Code has show that having a
> consistent look across systems is much more important than respecting
> the look of the OS).

I doubt that it would even be possible at all with our manpower to
implement "our own toolkit" on all platforms.  Especially on systems
like macOS, where AFAICT the system tries its best to prevent you from
implementing certain things yourself (such as tooltips and popup menus,
the former proved to be a royal pain in the neck earlier.)

Besides, how is that related to the success of Microsoft's VS Code?  I
think it is more related to how much support it gets from toolchain
developers, caused by Microsoft bundling it with their GitHub platform,
much like they bundled MSIE with Windows 95.  Cargo culting their choice
of toolkit will not do us much good.

> But we have to fix the no-toolkit look before we can contemplate that.
>
> 1) New toolbar icons:
>
>   
>
>
>
>
> We need somebody, preferably a designer, to put together a set of
> consistent (and pretty) toolbar icons.

The toolbar icons come from GNOME 2.x, so they are already consistent
and (mostly) put together by designers.  Aside from the ugly cross icon,
which really has to go.

> 2) Background glitches:
>
> I've got *background: black, and that makes "emacs -Q" look like this:
>
>
>
>
>
>
> That has to be fixed.

Just turn off the internal border, or specify the color of the internal
border in your X resources.  The default size of the internal border is
intentionally different across different builds and window systems, to
make up for different looking decorations.

> 3) Menu bar font:
>
>
>
>
> Must be proportional to not look like an artefact of the 80s.

I'd be glad if someone worked on that.  At the same time, we could make
RTL text work there as well.

> 4) HiDPI problems in the menus: The menus are unreadably small on a
> HiDPI display.

The fix is to specify a larger font for the menus.  But see below for
more problems with the oldXMenu library:

> 5) The scroll bar has to be fixed to work as modern scroll bars to, not
> emulate the actions of an 80s Xterm.  I.e., you have to be able to drag
> the scrool widget, and click above and below it, and have the thing
> happen that normal users expect.

I disagree, but that behavior should be made customizable.  The
"no-toolkit" scroll bar in general is a big hack that is not portable to
platforms other than X.

> Once those five things are in place, we should default to a no-toolkit
> build, which will give us a lot more control of Emacs behaviour, and not
> rely on odd tics in each toolkit, and in addition, allow
> daemon/multi-display shutdown to work reliably.

The no-toolkit build can not work on any other platform other than X.
The scroll bars are implemented by Emacs itself in a very non-portable
way, and the menus are implemented by the old XMenu library that came
with X10 and early X11 releases.

All of that amounts to a large amount of code that is very difficult to
replicate on other platforms.

Thanks.