Re: Abysmal state of GTK build

[Po Lu <luangruo@yahoo.com>]

Tim Cross <theophilusx@gmail.com> writes:

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

If they run into problems in GTK at that point, we can just shrug and
ask them to complain to the GTK developers.

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

I wouldn't call a stylesheet applied to only the menu bar and scroll bar
"consistent".  It is hard to keep a GTK stylesheet consistent anyway,
because their developers keep breaking the stylesheet format, and now
there are GTK 4 programs that do not allow applying custom styles at
all.

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

So, in other words, you're fine with the menu bar being consistent with
the system stylesheet (something the GTK developers say not to apply,
and have outright deleted from many GTK 4 programs), while a Gnus
summary buffer is not?

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

Again, see what I said above.

> 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 don't want to discourage people from manually selecting GTK.

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

Because the core input subsystem is obsolete, like Xinerama,
multi-buffering, the original input extension, core fonts, and RandR
before 1.2.  It will not even work with new input devices in the future,
or under multi-pointer X environments, and the support in GTK itself
will be removed by GTK developers at some point.  Do this:

  xinput create-master test 0 1
  xinput reattach <another pointer device> <id of test master pointer>

and try to click on a frame from programs not using the input extension.
It will not work.