Re: Abysmal state of GTK build

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> You missed my point. I'm not saying the change is because of a stylistic
>> issue - I'm saying the change is likely to create a stylistic
>> issue. This will in turn cause more resistance to the change and
>> possibly increase motivation to do whatever is necessary to re-enable
>> gtk build. 
>
> Reenabling the GTK build will be as easy as specifying
> "--with-x-toolkit=gtk" at configure-time.  It's not being deleted.
>

and again I feel your missing the point. Failing to address the
stylistic questions runs the risk that most people will just re-enable
the GTK theme. When this occurs, what have you actually achieved other
than now being able to say "Oh well, you chose GTK, so now its your
problem".

What is really required is that the default is changed away from GTK and
the majority of users are comfortable/happy with that change. This means
somehow addressing concerns which people are likely to raise with a
change in default toolkit. Dismissing them as irrelevant just because
they represent some current trend/style you find distasteful is unlikely
to help promote your proposal and gain acceptance. 

>> Yes, I know that and that is a problem for distributions where they want
>> to minimise the distro size and number of packages which need to be
>> maintained. As it stands now, most distributions include 3 packages -
>> emacs-gtk, emacs-lucid and emacs-nox. As they move to support wayland,
>> they will either have to include emacs-pgtk or continue with the
>> wayland-x interface. The risk is, given they need GTK for both emacs-gtk
>> and emacs-pgtk, they will drop the emacs-lucid package rather than the
>> emacs-gtk package (unless we help educate them on why that would be a
>> bad choice). To educate effectively, it helps to understand their
>> situation and not just address the technical issues seen from a pure
>> emacs development position.
>
> They don't need anything extra for emacs-notoolkit.
>

but they lose the ability to easily adopt a consistent theme across
their desktop - something which for whatever reason appears to work now
and will not once you change to either no toolkit or lucid.

>> OK, so how does my Emacs default theme change between dark and light
>> theme when I change the theme of my desktop environment? This never use
>> to work and I assumed it was because emacs didn't respect the DE
>> theme. I use to manage it via X resources. However, I noticed on recent
>> installs under both Ubuntu and Fedora that changing between light and
>> dark themes also resulted in changes to (for example) the menus and
>> menu-bar from a light background with dark text to a dark background
>> with light text. My assumption was that this was due to the GTK theme
>> being respected?
>
> The menu bar is not part of Emacs's own interface.
>

I don't really understand what you mean with this above statement. From
a user perspective, the menu-bar is obviously a part of the Emacs
interface and when I switch to lucid or no toolkit, it changes to a
light background and a dark foreground while everything else on my
desktop honours my selection of a dark background and a light
foreground. If I run the GTK build, the foreground/background is the
same as the other apps on my desktop i.e. dark background, light
foreground.

As outlined at the very beginning, this consistency in themes seems to
be something users want as can be seen in the prevalence of discussions
and reviews regarding recent GNU Linux distribution releases which focus
on this aspect. To minimise push-back and increase acceptance for a
toolkit default change, addressing such side issues will likely help
ensure a smoother transition. 

>> Which is fine for those who know lisp. However, this isn't what people
>> expect these days. THis was my point - lots of the comments and reviews
>> for recent distributions of Ubuntu and Fedora have referenced greatly
>> improved theme/style consistencies. From my own limited experience, this
>> appears to extend to Emacs as well (to a limited extent, not the whole
>> UI, just menus, popup dialogue boxes etc.
>
> You can use Customize too, if you want.
>

still missing the point. Users don't want to be required to go through
each individual application and manually adjust the theme to get a
consistent looking desktop. They have selected a desktop environment and
set a theme and want it applied consistently across the desktop. This
appears to be something they have with current GTK build and which you
don't get with lucid or no toolkit builds (at least on the Ubuntu and
Fedora DE I've used, YMMV with other combinations). I don't know how
easy it would be to address this issue - weather it would be possible to
add a basic 'interface' package or script or document some alternative
approaches to help people get the consistency which seems important with
minimal effort. 


>> Ignoring the level of motivation visual appeal/style has to peoples
>> decisions is likely to be somewhat naive. There are plenty of examples
>> of superior technology/solutions losing to inferior ones because of
>> non-technical reasons.
>
> That doesn't mean it's a good idea to base our decisions on those
> non-technical reaspons.
>

and that isn't what I said or suggested. At the risk of repeating myself
yet again, I'm not against the change in default toolkit. I'm merely
suggesting that if you want to minimise the push back to this change and
discourage people just manually selecting GTK, you need to also try and
address these separate, but related issues. Dismissing them as just
being irrelevant 'modern' trends will generate more heat and resistance
than necessary. 

>> I also wonder about how frequent these crashes and technical issues
>> are. I switched over from gtk to lucid a little while ago. However,
>> prior to switching, I experienced absolutely no issues and I cannot
>> recall the last time Emacs crashed for me. I'm running latest emacs
>> devel (29.0.50) on Fedora 36 (previously on Ubutnu 22.04). I'm a heavy
>> Emacs users, running it every day all day and using it for nearly
>> everything. I switched to lucid because the technical arguments made
>> sense to me. However, I did not experience any of the technical issues
>> you reference. If my experience is more common, then your purely
>> technical argument is going to have difficulty gaining traction.
>
> I'm going to say that you're simply lucky.  Search for "GTK" on the bug
> tracker, in etc/PROBLEMS, and on this list, and you will see what I mean
> very quickly.

However, that only gives a one sided view - all those people using the
GTK build who don't experience any problems don't report all is OK.

All I can report on is my personal experience. For me, I see no
instability with the GTK build. I also see little of benefit to me with
the switch to the new xinput2 and wonder why not just disable xinput2 in
just the GTK build so that if/when users select GTK as their preferred
toolkit, it is at least stable. I think it is quite reasonable to tell
people that if they want the features, such as pixel level scrolling,
then they have to use either no tookit or lucid and that the xinput2
features are not available in GTK.

It seems misguided to just change the default from GTK to no toolkit or
lucid and leave the ability to select GTK knowing that will cause
instability due to the use of xinput2. Change the default AND disable
xinput2 when someone selects the GTK toolkit.