Support touch scroll in register; remove legacy scroll interactions

[adamwight]

Just as an experiment, I'd like to compare how standard scrolling behavior feels in the register view. I find the current fast and quantized scroll to be disconcerting, but I recognize that a lot of thought, and trial and error, have already gone into the existing custom scroll interactions.

This patch replaces custom scrolling with a ScrolledWindow container and its default handlers.

Reviewers: if you like this simplification, please suggest any legacy scrolling behaviors which should be reinstated.

[Bob-IT]

@adamwight What are you testing on ?
I have tested on my Linux VM and scrolling does not work properly, I have added some screen shots below...

The vertical scrollbar will not move up any further even though there a three more transactions above.

Would need to decide what to do with the white space in top right, maybe useful for something?

This time I have shrunk the width on Gnucash, again the vertical scrollbar is wrong and also the white space is gone.

This shows the horizontal scroll bar over the last transaction with the vertical at the bottom.

[adamwight]

Great feedback, thank you! I'm using gnome3-desktop and the scrollbars disappear when not scrolling. This results in an appearance which seems correct to me. But I see from your screenshots that we can't safely assume this behavior, sometimes the scrollbars will be displayed. I was hoping this line would cause scrollbars to disappear by default:

gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW(swin),
                                    GTK_POLICY_AUTOMATIC,
                                    GTK_POLICY_AUTOMATIC);

Here are screenshots of the beginning and end of the register when the bars disappear:

The first and last transactions are correct.

While scrolling, the bars cover some content but I think that's normal:

So I wonder if the solution is to make the scrollbars more aggressively disappear on all platforms, or to adapt the layout in case of non-disappearing scrollbars?

[jralls]

@adamwight We've been running this experiment for 20 years. All of the special-case code is there to deal with a problem some user had. Unless you have hardware to test with several input devices (trackpad, trackball, mouse, graphics tablet) on both Linux windowing systems (XOrg and Wayland) as well as Windows and macOS and the time to test all of those combinations you're not going to be able to detect regressions. Expecting the developers to do that for you is an unfair demand on their time.

BTW, mac trackpads behave as "touch" devices for the purposes of "touch scroll". Works fine with the GnuCash register, I've been using them for 6-7 years.

[adamwight]

I was able to reproduce @Bob-IT 's regression by setting GTK_OVERLAY_SCROLLING=0 in ~/.profile . I'll play around to see how layout might be adapted to this condition.

@jralls Tremendous work done on this package so far! I was intrigued by what I've seen, and it seems to be a friendly and helpful community. I'm familiar with some of the challenges of maintaining a legacy code base and I tend to agree with you that tearing everything to the ground is rarely a good idea.

The reason I made this patch was because I noticed two current gnucash quirks that marred my otherwise pleasant user experience:

• Touchscreen interaction is not working for the register view on my platform. It works fine on other pages such as reports and table views.
• Scrolling a large register with my small touchpad (maybe half the size of a Mac touchpad, at 6 cm diagonal) causes lines to go by far too quickly. The smallest increment of scroll is roughly 8 rows, and a slight hand motion scrolls hundreds of rows.

Looking into the code, I see quite a lot of special handling for various types of scrolling, but only for the register view. It suggests a smell, especially since this is the view which is giving me problems. As a step in debugging, I disconnected all of the custom scroll logic and this resulted in a surprisingly nice standard interaction, at least to my own taste.

If project developers recommend that I rework the patch to strictly add touchscreen support without affecting the existing customizations, I'd be happy to do so. Or if touchscreen isn't an imagined use case then it's fine to drop the investigation, too.

[jralls]

Looking into the code, I see quite a lot of special handling for various types of scrolling, but only for the register view. It suggests a smell, especially since this is the view which is giving me problems. As a step in debugging, I disconnected all of the custom scroll logic and this resulted in a surprisingly nice standard interaction, at least to my own taste.

Oh, it's smelly alright. That's because it's far too customized for its own good. @Bob-IT tried to rewrite it based on standard GtkWidgets a few years ago but getting all of the behaviors close enough to the original to keep users happy turned out to be too hard and he set it aside to bitrot.

Scrolling a large register with my small touchpad (maybe half the size of a Mac touchpad, at 6 cm diagonal) causes lines to go by far too quickly. The smallest increment of scroll is roughly 8 rows, and a slight hand motion scrolls hundreds of rows.

See the comment and code starting at

gnucash/gnucash/register/register-gnome/gnucash-sheet.c

Line 1380 in 0650f56

/* GdkQuartz reserves GDK_SCROLL_SMOOTH for high-resolution touchpad

. Sounds like your touchpad might be falling on the wrong side of that.

Touchscreen interaction is not working for the register view on my platform. It works fine on other pages such as reports and table views.

What platform is that and what's the problem?

If project developers recommend that I rework the patch to strictly add touchscreen support without affecting the existing customizations, I'd be happy to do so. Or if touchscreen isn't an imagined use case then it's fine to drop the investigation, too.

Touchscreen use hasn't come up before, so let's try to figure out what's going wrong before we decide whether fixing it is too hard. Making sure that there aren't any regressions for anybody else definitely falls into the too hard category though so please do focus on getting your touchscreen working.