Dear Debian GTK+ Maintainers,

I'm thinking of moving to Debian Stretch from Jessie. I have already
started trying it out on Virtualbox, however I always get sick of GTK3. It
is just driving me crazy. The more its development advances the more
annoyances affecting usability and productivity are introduced which makes
me end up willing to scream something like "I'm not using a damn iPad /
Android tablet, this is a desktop computer!!!!" every time. Since I'm
really sensitive to feature removals, dumbed-down user interfaces, UI
changes based on pure fashion (e.g. tabletized desktop interfaces), and the fact that EoL of Jessie LTS is near, I must find a solution. So what should
I do with a piece of open-source software that has gone awry? First thing
that pops into my mind is reverting the hell out of those nasty commits
causing the unwanted behavior. I'm neither a maintainer myself nor a programmer. Just a sysadmin with 10 years in the field who uses Linux
desktop on a daily basis with my favorite distro Debian that I'm using
almost since the beginning. I highlighted desktop with bold, because it's
not a tablet, not a smartphone, so I don't want it to work like a tablet or look like a tablet. I also don't care if guys at Gnome and Red Hat don't
have a better idea than aping even dumber UIs of Google Android and
Microsoft (Metro) with their shitty UI designs.

I try to avoid GTK3 as much as possible but there are some vital
applications at which I just can't. For example, Google Chrome as well as Chromium which I wouldn't want to patch and re-compile ever. They default
to the GTK3 file dialog which is the single worst file chooser ever
developed. I would like to get rid of the following annoyances hardcoded
into GTK3.

I also managed to recompile Xfce 4.12.3 with GTK2 using Debian Stretch
source packages. So far it runs without problems. So I thought I'd do the
same with libgtk-3-0 but it doesn't seem that easy at first.

1. Scrolling Indicator Cursor
Every time I scroll inside GTK3 File Chooser, a cross cursor is shown,
which I don't want to be there. Default cursor used to stay during
scrolling and it should stay. I'm not a lame dumb f*ck who doesn't know
what sort of gesture he's just made on the touchpad. If I want to scroll,
it's intentional from my side. I don't need the mouse cursor to be changed
to know that I'm scrolling. If I scroll, I should see list items (files and folders) moving within the file dialog. That's enough visual response for
me. I find the scrolling indicator cursor annoying. I find it offensive
that it's hardcoded and I can't turn that off via gsettings or gtk.ini. I
would like to turn that off. It seems to have been introduced in commit de8af768 <https://gitlab.gnome.org/GNOME/gtk/commit/de8af768974b12e6b290fb813ed45bbb66a24f16>,
however I need some advice on how to revert it properly as there are also further changes based on it (e.g. by commit 9eb356d9 <https://gitlab.gnome.org/GNOME/gtk/commit/9eb356d9f29a881e05937a0089d88154cfc6364a>
).

2. Overshoot Animation
Another annoyance that is basically aping iOS/Android scroll widgets. Since
I'm still not using a smartphone or a tablet but a desktop computer, I
would like to get rid of this feature completely. Which means I don't even
want to mess around with CSS hacks <https://unix.stackexchange.com/questions/250880/how-to-disable-or-fix-gtk-scrolling-indicators>
as they're tied to particular themes. Plus I don't even want an event to be fired by the underlying GUI toolkit when I reach the bottom of the
scrollable area and then try to overscroll. I don't want CPU cycles to be wasted for firing useless events like that. I just want the good old
behavior. No animation, no indicator of overshooting, no overshoot events.
I find the overshoot animation annoying. I find it offensive that it's hardcoded and I can't turn that off via gsettings or gtk.ini. It seems to
have been introduced in commit 103e11c9 <https://gitlab.gnome.org/GNOME/gtk/commit/103e11c9372c1fbdb6bd8311b7b7f2ee9981ccf8>,
however I need some advice on how to revert the changes properly as there
are a lot of futher changes based on it.

3. Recursive directory search
Most annoying of all. When I'm in GTK3 File Chooser and start typing, the
file dialog will start off a recursive search traversing through all my directories, on a type-to-find basis. I can't type-ahead a file in the
current directory any more, which allowed me to quickly jump to a file by typing its initial letters. The new behavior is pretty annoying, raises
many concerns regarding performance, privacy and general usability. It has already been discussed in many bug reports and forums. [1] <https://gitlab.gnome.org/GNOME/gtk/issues/839> [2] <https://bugzilla.gnome.org/show_bug.cgi?id=748672> [3] <https://mail.gnome.org/archives/nautilus-list/2012-August/msg00002.html>
[4] <https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016> [5] <https://bugzilla.gnome.org/show_bug.cgi?id=772634> [6] <https://bugzilla.gnome.org/show_bug.cgi?id=784029> A proposed patch / pull request <https://bugzilla.gnome.org/show_bug.cgi?id=753892#c6> has also
been created but stubborn GNOME developers don't even want to understand
why their forced recursive search is an issue. They don't hesitate to push their will down every single desktop Linux user's throat, without giving an option to restore the old behavior. It seems to have been introduced in
commit b3c28e14 <https://gitlab.gnome.org/GNOME/gtk/commit/b3c28e14fe184ee61f1904021ba42af5052bc9da>,
however I need some advice on how to revert the changes properly as there
are a lot of further changes based on it.

I don't really want to start an argument about why maintainers have let all
the menace coming with GTK3 into Stretch, because I'm afraid we would end
up somewhere like those systemd-related discussions in the past, without finding a constructive solution. I also don't want to adapt to these annoyances. If that was an option for me, I wouldn't have turned to you
with this e-mail.

If there is no chance of maintainers doing this (which is very likely
because Stretch has already been code-frozen) then I would like to ask for
help on how to revert the changes that introduced the annoyances above,
while maintaining stability. And I mean all of them, without any compromise.

I appreciate any help on finding a sustainable way of patching GTK3 in
Debian Stretch source packages to achieve the goals above. Alternatively
I'm okay with a system-wide setting in every GTK3-dependent application
where I can replace GTK3 File Chooser with GTK2 File Chooser, however I
highly doubt this is possible.

Best Regards,
Pál Tamás Ács

<div dir="ltr"><div>Dear Debian GTK+ Maintainers,<br></div><div dir="ltr"><div class="gmail-postbody"><p class="gmail-author"></p>



<div class="gmail-content">I&#39;m thinking of moving to Debian Stretch from Jessie. I have
already started trying it out on Virtualbox, however I always get sick
of GTK3. It is just driving me crazy. The more its development advances
the more annoyances affecting usability and productivity are introduced
which makes me end up willing to scream something like &quot;I&#39;m not using a
damn iPad / Android tablet, this is a desktop computer!!!!&quot; every time. Since I&#39;m really sensitive to feature removals, dumbed-down user interfaces, UI changes based on pure fashion (e.g. tabletized desktop interfaces), and the fact that EoL of Jessie LTS is near, I must find a solution. So what should I do with a piece of open-source software that
has gone awry? First thing that pops into my mind is reverting the hell
out of those nasty commits causing the unwanted behavior. I&#39;m neither a maintainer myself nor a programmer. Just a sysadmin with 10 years in the
field who uses Linux <span style="font-weight:bold">desktop</span> on a
daily basis with my favorite distro Debian that I&#39;m using almost since the beginning. I highlighted desktop with bold, because it&#39;s not a
tablet, not a smartphone, so I don&#39;t want it to work like a tablet or
look like a tablet. I also don&#39;t care if guys at Gnome and Red Hat don&#39;t
have a better idea than aping even dumber UIs of Google Android and
Microsoft (Metro) with their shitty UI designs.<br><br>I try to avoid
GTK3 as much as possible but there are some vital applications at which I
just can&#39;t. For example, Google Chrome as well as Chromium which I wouldn&#39;t want to patch and re-compile ever. They default to the GTK3
file dialog which is the single worst file chooser ever developed. I
would like to get rid of the following annoyances hardcoded into GTK3.<br><br>I
also managed to recompile Xfce 4.12.3 with GTK2 using Debian Stretch
source packages. So far it runs without problems. So I thought I&#39;d do
the same with libgtk-3-0 but it doesn&#39;t seem that easy at first.<br><br><span style="font-size:150%;line-height:116%"><span style="font-weight:bold">1. Scrolling Indicator Cursor</span></span><br>Every
time I scroll inside GTK3 File Chooser, a cross cursor is shown, which I
don&#39;t want to be there. Default cursor used to stay during scrolling
and it should stay. I&#39;m not a lame dumb f*ck who doesn&#39;t know what sort
of gesture he&#39;s just made on the touchpad. If I want to scroll, it&#39;s <span style="font-weight:bold">intentional</span>
from my side. I don&#39;t need the mouse cursor to be changed to know that I&#39;m scrolling. If I scroll, I should see list items (files and folders) moving within the file dialog. That&#39;s enough visual response for me. I find the scrolling indicator cursor annoying. I find it offensive that it&#39;s hardcoded and I can&#39;t turn that off via gsettings or gtk.ini. I would like to turn that off. It seems to have been introduced in commit <a href="https://gitlab.gnome.org/GNOME/gtk/commit/de8af768974b12e6b290fb813ed45bbb66a24f16" class="gmail-postlink">de8af768</a>, however I need some advice on how to revert it
properly as there are also further changes based on it (e.g. by commit <a href="https://gitlab.gnome.org/GNOME/gtk/commit/9eb356d9f29a881e05937a0089d88154cfc6364a" class="gmail-postlink">9eb356d9</a>).<br><br><span style="font-weight:bold"><span style="
font-size:150%;line-height:116%">2. Overshoot Animation</span></span><br>Another annoyance that is basically aping iOS/Android scroll widgets. Since I&#39;m still not using a smartphone or a tablet but a <span style="font-weight:bold">desktop</span>
computer, I would like to get rid of this feature <span style="font-weight:bold">completely</span>. Which means I don&#39;t even want to mess around with <a href="https://unix.stackexchange.com/questions/250880/how-to-disable-or-fix-gtk-scrolling-
indicators" class="gmail-postlink">CSS hacks</a>
as they&#39;re tied to particular themes. Plus I don&#39;t even want an event to be fired by the underlying GUI toolkit when I reach the bottom of the
scrollable area and then try to overscroll. I <span style="font-weight:bold">don&#39;t want CPU cycles to be wasted</span>
for firing useless events like that. I just want the good old behavior.
No animation, no indicator of overshooting, no overshoot events. I find
the overshoot animation annoying. I find it offensive that it&#39;s
hardcoded and I can&#39;t turn that off via gsettings or gtk.ini. It seems
to have been introduced in commit <a href="https://gitlab.gnome.org/GNOME/gtk/commit/103e11c9372c1fbdb6bd8311b7b7f2ee9981ccf8" class="gmail-postlink">103e11c9</a>, however I need some advice on how to revert the changes properly as there are a lot of
futher changes based on it.<br><br><span style="font-size:150%;line-height:116%"><span style="font-weight:bold">3. Recursive directory search</span></span><br>Most
annoying of all. When I&#39;m in GTK3 File Chooser and start typing, the
file dialog will start off a recursive search traversing through all my directories, on a type-to-find basis. I can&#39;t type-ahead a file in the current directory any more, which allowed me to quickly jump to a file
by typing its initial letters. The new behavior is pretty annoying,
raises many concerns regarding performance, privacy and general
usability. It has already been discussed in many bug reports and forums.
<a href="https://gitlab.gnome.org/GNOME/gtk/issues/839" class="gmail-postlink">[1]</a> <a href="https://bugzilla.gnome.org/show_bug.cgi?id=748672" class="gmail-postlink">[2]</a> <a href="https://mail.gnome.org/archives/nautilus-list/2012-August/msg00002.
html" class="gmail-postlink">[3]</a> <a href="https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016" class="gmail-postlink">[4]</a> <a href="https://bugzilla.gnome.org/show_bug.cgi?id=772634" class="gmail-postlink">[5]</a> <a href="https://
bugzilla.gnome.org/show_bug.cgi?id=784029" class="gmail-postlink">[6]</a> A <a href="https://bugzilla.gnome.org/show_bug.cgi?id=753892#c6" class="gmail-postlink">proposed patch / pull request</a>
has also been created but stubborn GNOME developers don&#39;t even want to understand why their forced recursive search is an issue. They don&#39;t hesitate to push their will down every single desktop Linux user&#39;s
throat, without giving an option to restore the old behavior. It seems
to have been introduced in commit <a href="https://gitlab.gnome.org/GNOME/gtk/commit/b3c28e14fe184ee61f1904021ba42af5052bc9da" class="gmail-postlink">b3c28e14</a>, however I need some advice on how to revert the changes properly as there are a lot of
further changes based on it.<br><br>I
don&#39;t really want to start an argument about why maintainers
have let all the menace coming with GTK3 into Stretch, because I&#39;m
afraid we would end up somewhere like those systemd-related discussions
in the past, without finding a <span style="font-weight:bold">constructive</span> solution. I also don&#39;t want to adapt to these annoyances. If that was an option for me, I wouldn&#39;t have turned to you with this e-mail.<br><br>If
there is no chance of maintainers doing this (which is very likely
because Stretch has already been code-frozen) then I would like to ask
for help on how to revert the changes that introduced the annoyances
above, while maintaining stability. And I mean all of them, without any compromise.<br><br>I appreciate any help on finding a sustainable way of <span style="font-weight:bold">patching GTK3 in Debian Stretch source packages</span> to achieve the goals above. Alternatively I&#39;m okay with a system-wide setting in every GTK3-
dependent application where I can <span style="font-weight:bold">replace GTK3 File Chooser with GTK2 File Chooser</span>, however I highly doubt this is possible.<br><br></div><div class="gmail-content">Best Regards,<br></div><div class="gmail-content">P�
�l Tamás Ács<br></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Apr 7, 2019 at 10:58 PM Pál Tamás Ács wrote:

Dear Debian GTK+ Maintainers,

I'm not one of those, but hopefully my answer is helpful anyway.

So what should I do with a piece of open-source software that has gone awry?

In general, there are several of options for software with behaviour
you don't like (in order of decreasing time commitment):

Learn to live with the new behaviour.

Reconfigure the software to change the behaviour if that is possible.

Add some extensions or hacks to the software to change the behaviour
if that is possible.

Switch to other software that doesn't have that behaviour.

Report a bug to Debian or upstream. Wait for the maintainer of the
Debian package to forward it upstream (or do that yourself). Wait for
upstream to read the issue. Wait for upstream to prioritise the issue.
Wait for upstream to fix the issue. Wait for upstream to make a new
release containing the fix. Wait for the maintainer of the Debian
package to import the new upstream release. Wait for Debian to make a
new release containing the issue. Upgrade to the new Debian release.

Edit the latest upstream code. Request your changes get merged
upstream. Backport the changes to the version you are using. Rebuild
the Debian package with your backport and install it. Request your
backport gets merged upstream (if there is an LTS branch). Request
that Debian update to the latest version on the LTS branch.

Write new software that has the behaviour you want.

I highlighted desktop with bold

HTML mail should not be used on the Debian mailing lists. In addition,
I understand your frustration, but some parts of your mail are a bit
flamy, it would be nice if you could avoid that in future posts.

https://www.debian.org/MailingLists/#codeofconduct https://www.debian.org/code_of_conduct

I try to avoid GTK3 as much as possible

During the Debian bullseye cycle (stretch+2), it is likely that
GTK2-only applications will be removed from Debian and other
applications upgraded to GTK3/GTK4 as GTK2 is deprecated. I expect
that some upstreams will drop support for GTK2 entirely. So I think
the most sustainable approach would be for you to either convince the
GTK developers to make it more configurable (I guess that is unlikely)
or to patch GTK for yourself and rebuild it after every update to GTK.

1. Scrolling Indicator Cursor
Every time I scroll inside GTK3 File Chooser, a cross cursor is shown

This behaviour is not triggered on desktop systems with a mouse, only
on touchpads and other places where kinetic scrolling is possible.

I find the scrolling indicator cursor annoying.
I need some advice on how to revert it properly

I think if you comment out the call to gtk_widget_set_cursor_from_name
in the install_scroll_cursor function and the call to the
gtk_widget_set_cursor in the uninstall_scroll_cursor function in gtk/gtkscrolledwindow.c and then rebuild GTK3 then this behaviour
should get disabled.

2. Overshoot Animation
I find the overshoot animation annoying.
I need some advice on how to revert the changes properly

I'm not entirely sure and I have not tested this, but I think that if
you set smooth_scroll to FALSE in the scroll_controller_scroll_begin
function in gtk/gtkscrolledwindow.c and then rebuild GTK3 then this
behaviour should get disabled. If that doesn't work, then changing the
return line to "return FALSE;" (without quotes) in the _gtk_scrolled_window_get_overshoot function in gtk/gtkscrolledwindow.c
might work.

3. Recursive directory search
Most annoying of all.
I need some advice on how to revert the changes properly

I'm not entirely sure and I have not tested this, but I think that if
you change the OPERATION_MODE_SEARCH values to OPERATION_MODE_BROWSE
in the widget_key_press_cb function in gtk/gtkfilechooserwidget.c and
then rebuild GTK3 then this behaviour should get disabled.

If there is no chance of maintainers doing this (which is very likely because Stretch has already been code-frozen)

Both Debian stretch and buster are frozen for changes other than
security updates. In addition, it is unlikely that Debian would
deviate from GTK upstream's behaviour anyway due to the extra
maintenance burden of having additional Debian-specific patches.

I appreciate any help on finding a sustainable way of patching GTK3 in Debian Stretch source packages to achieve the goals above.

Unfortunately Debian doesn't make keeping long-term local patches
easy. The apt-build & apt-src packages might be able to help with
that.

Personally, I'd keep a git clone of the upstream GTK repo with my
personal patches. Then export the patches and copy them into the
Debian source package patch directory, rebuild in sbuild/pbuilder,
install the binary packages, delete the Debian source package again
and repeat for each rebuild after each GTK update.

where I can replace GTK3 File Chooser with GTK2 File Chooser

I don't think this is a sustainable option, but ISTR there are ways to
use the KDE file chooser in GTK-based programs when running on KDE.
You could look into emulating that under GNOME.

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)