[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Abysmal state of GTK build
From: |
Lars Ingebrigtsen |
Subject: |
Re: Abysmal state of GTK build |
Date: |
Sun, 21 Aug 2022 13:49:22 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Po Lu <luangruo@yahoo.com> writes:
> Users of the GTK 3 build experience many, many problems. The most
> recent such problem is bug#56869, which is definitely a bug in GTK.
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.
> Taking into account the very low quality of the GDK X11 backend, which
> is not seeing active maintenance, shouldn't the build default to some
> other toolkit such as Motif, or even better, no toolkit at all?
>
> Especially considering that a GTK developer (the tail) wants to remove
> support for X11 (the dog) in future releases of GTK:
>
> https://gitlab.gnome.org/GNOME/gtk/-/issues/5004
Love the ending there:
"Since this issue found its way on Phoronix and reddit I'm going to
temporarily lock it, to ensure a modicum of decency and avoid lowering
the bar of the comments."
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).
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.
2) Background glitches:
I've got *background: black, and that makes "emacs -Q" look like this:
That has to be fixed.
3) Menu bar font:
Must be proportional to not look like an artefact of the 80s.
4) HiDPI problems in the menus: The menus are unreadably small on a
HiDPI display.
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.
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.
- Re: Abysmal state of GTK build, (continued)
- Re: Abysmal state of GTK build, Po Lu, 2022/08/23
- Re: Abysmal state of GTK build, Richard Stallman, 2022/08/23
- Re: Abysmal state of GTK build, Po Lu, 2022/08/21
- Re: Abysmal state of GTK build, Visuwesh, 2022/08/21
- Re: Abysmal state of GTK build, Po Lu, 2022/08/21
- Re: Abysmal state of GTK build, Visuwesh, 2022/08/22
- Re: Abysmal state of GTK build, Po Lu, 2022/08/21
- Re: Abysmal state of GTK build, Richard Stallman, 2022/08/22
- Re: Abysmal state of GTK build, Akib Azmain Turja, 2022/08/23
- Re: Abysmal state of GTK build, Po Lu, 2022/08/23
Re: Abysmal state of GTK build,
Lars Ingebrigtsen <=
- Re: Abysmal state of GTK build, Lars Ingebrigtsen, 2022/08/21
- Re: Abysmal state of GTK build, Po Lu, 2022/08/21
- Re: Abysmal state of GTK build, Lars Ingebrigtsen, 2022/08/21
- Re: Abysmal state of GTK build, Lars Ingebrigtsen, 2022/08/21
- Re: Abysmal state of GTK build, Po Lu, 2022/08/21
- Re: Abysmal state of GTK build, Lars Ingebrigtsen, 2022/08/21
- Re: Abysmal state of GTK build, Po Lu, 2022/08/21
- Re: Abysmal state of GTK build, Lars Ingebrigtsen, 2022/08/21
- Re: Abysmal state of GTK build, Po Lu, 2022/08/21
- Re: Abysmal state of GTK build, Lars Ingebrigtsen, 2022/08/21