restore horizontal scrollbar in the project manager plugin
AbandonedPublic

Authored by apol on Jun 11 2017, 4:07 PM.

Details

Reviewers
kfunk
rjvbb
Group Reviewers
KDevelop
Summary

An old comment in the ProjectManagerView ctor mentions a horizontal scrollbar, something I cannot remember having seen in the KDevelop5 project manager, and that I've sorely missed.

This patch restores that feature, doing away with elided filename representation. The crucial change is setting setStretchLastSection(false) and the addition of a resizeEvent filter that sets the header's minimum section size appropriately. This was copied from Qt Creator's navigator widget implementation.

The tooltip feature showing the full filename remains functional so I think (and hope) there is no need to provide a UI configuration option to allow users to select either the new or the old behaviour.

Test Plan

tested on Mac and Linux, developed on the 5.1 branch.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
rjvbb created this revision.Jun 11 2017, 4:07 PM
Restricted Application added a subscriber: kdevelop-devel. · View Herald TranscriptJun 11 2017, 4:07 PM
rjvbb edited the test plan for this revision. (Show Details)Jun 11 2017, 4:08 PM
apol added a subscriber: apol.Jun 11 2017, 11:08 PM

Why would we need to scroll horizontally when you can make the panel bigger?

In D6184#115711, @apol wrote:

Why would we need to scroll horizontally when you can make the panel bigger?

I've been asking myself to opposite question - so why would you not be able to do both? The patch just (re)enables support for horizontal scrolling, it doesn't make using them compulsory

kfunk requested changes to this revision.Jul 6 2017, 5:48 PM
kfunk added a subscriber: kfunk.

To be honest I'm a lot happier with the current behavior, i.e. eliding the text if there's not enough space. Horizontal scrolling on desktop (esp. without touch) is not considered the best UX.

To me this patch is a no-go, too.

This revision now requires changes to proceed.Jul 6 2017, 5:48 PM
rjvbb added a comment.Jul 6 2017, 9:59 PM

This revision now requires changes to proceed.

What changes?

Who doesn't have a touch- or trackpad nowadays, or a mouse with scrollwheel?
I guess I must be grateful that the text editor still scrolls, after all I could get a larger or additional screen if my files are too big or have lines that are too long? :P

Whatever, another patch I'll just keep for myself...

Just my two cents: I work with a touch pad most of the time and wouldn't like horizontal scrolling in the project manager. The problem is that it wobbles left and right when all you want is to scroll up and down. I'm also not using it in the source code view, instead the dynamic word wrap helps me to break long lines, if they occur.

Horizontal scrolling is nice for images, where you have two equivalent dimensions, or similar media. Text however (or a directory tree) extends mostly in the vertical dimension, while the horizontal extent should ideally be a small constant. In these cases you don't want horizontal scrolling, because it destroys the alignment that helps the user orient. Which is especially important in source code, or a directory tree. As @kfunk said, it's really not a good idea UX-wise.

However, I've seen implementations where elided text is immediately expanded on hovering, which is quite nice. That isn't happening here, instead I have to wait some time for a tool tip that shows the entire path. That might be a bit annoying.

rjvbb added a comment.Jul 8 2017, 12:45 PM

In these cases you don't want horizontal scrolling, because it destroys the alignment that helps the user orient. Which is especially important in source code, or a directory tree.

?? Who said my change implements per-line scrolling? The whole view is scrolled, just like in a text view where alignment is also not "destroyed" as you claim. Wrapping is much more detrimental to orientation.

I agree scrolling is very sensitive, it might be possible to do something about that via an event filter. You get used to it though, and use of a touchpad under Linux requires a bit of patience setting things up correctly (and even then it won't work as well as a Mac touchpad does). There's a trick too if you're using 2-finger scrolling: just scroll a tad towards the left to keep the view left-aligned. Or use the scrollbar...

Maybe one can filter out horizontal wheel events so that horizontal scrolling is possible only via the horizontal scrollbar? Of course you can do that for the entire desktop via the touchpad KCM...

However, I've seen implementations where elided text is immediately expanded on hovering, which is quite nice. That isn't happening here, instead I have to wait some time for a tool tip that shows the entire path. That might be a bit annoying.

You have to wait for a tooltip and hope it will - and even if it does you get the entire filename of only a single entry. Which is more than just a bit annoying if you try to open a specific file from a list of files that all look the same in the project view because the differences are hidden in the elided part.

Would it be technically feasible to toggle from one mode to another by pressing a modifier key?

In D6184#122970, @rjvbb wrote:

In these cases you don't want horizontal scrolling, because it destroys the alignment that helps the user orient. Which is especially important in source code, or a directory tree.

?? Who said my change implements per-line scrolling? The whole view is scrolled, just like in a text view where alignment is also not "destroyed" as you claim. Wrapping is much more detrimental to orientation.

I completely understand your proposal. I was trying to say that if I'm scrolling horizontally, the alignment on the screen is destroyed. So if one directory level is n pixels indented, and I'm scrolling a bit, the level might have an indentation of mn, and another level might have indentation n. That doesn't make it easier to orient.

There is a reason why most PDF viewers scale to the width of the window. There is a reason why web pages are written to adapt to the width of the browser view. All of this is to avoid horizontal scrolling.

Let's not discuss wrapping here, since it is irrelevant to the change in question.

I agree scrolling is very sensitive, it might be possible to do something about that via an event filter. You get used to it though, and use of a touchpad under Linux requires a bit of patience setting things up correctly (and even then it won't work as well as a Mac touchpad does). There's a trick too if you're using 2-finger scrolling: just scroll a tad towards the left to keep the view left-aligned. Or use the scrollbar...

I'm aware of the tricks, but I don't think it's wise to make users having to learn them.

Would it be technically feasible to toggle from one mode to another by pressing a modifier key?

I'd even argue for only showing the completion. The full path of a file is probably rarely required. Also, since I can't copy-and-paste from tool tips, it's not that helpful anyway.

rjvbb added a comment.EditedJul 9 2017, 7:48 AM

Aaron Puchert wrote on 20170708::22:25:18 re: "D6184: restore horizontal scrollbar in the project manager plugin"

... and another level might have indentation n. That doesn't make it easier to orient.

Let's be clear, I don't think one uses the projectmanager to do complex navigation in which you need to an overview of the entire tree layout in front of your eyes. Rather, you navigate a project with it, the general layout of which you presumably know rather well. In my own typical use I tend to work mostly in isolated subparts of a project, where I find it very useful to be able to align the project tree inside the toolview so that I have the most effective view of the contents where I can access the files directly.

I agree that the structure of the KDevelop project itself (KDevPlatform included) is particularly complex which probably stresses any project manager to its limits.

There is a reason why most PDF viewers scale to the width of the window. There is a reason why web pages are written to adapt to the width of the browser view.

2 different applications, and both type of applications usually provide both keyboard and/or touchpad zooming + scrolling (and more and more webpages seem written to use the entire width of my screen without taking window width into consideration ... and the browser doesn't even provide a scrollbar).

I'm aware of the tricks, but I don't think it's wise to make users having to learn them.

The same applies to the tricks required to figure out how to see the entire filename, or have them resize the toolview continuously.

As to setting up the touch/trackpad, I think that's something we should assume that users will have done so the equipment works "optimally" for them.

As far as I'm concerned that includes having disabled horizontal 2-finger scrolling if that doesn't work for them, because that same feature will cause the same trouble everywhere if you cannot master it.
Still, I'm trying to write a wheel event handler that will filter out the horizontal component from the events unless we know they come from a scroll wheel. For now I have managed only to achieve the opposite (https://stackoverflow.com/questions/44991025/qt5-filtering-out-the-horizontal-component-from-wheel-events) :-/

FWIW, I didn't want to propose making this a configuration setting, but apparently that's where we headed.

And note that this whole discussion applies to scrolling with a touchpad. Users with a mouse with a scroll wheel don't have this problem; the wheel scrolls in 1 direction at a time only (on Mac the system or Qt generates horizontal scrolling when using the wheel with the Shift modifier).

rjvbb updated this revision to Diff 16383.Jul 9 2017, 2:11 PM
rjvbb edited edge metadata.

I'm beginning to understand the objections from X11 users. Even with my settings horizontal scrolling behaves as if it's configured to scroll at least half the viewport width at a time. On Mac/Cocoa, horizontal and vertical scrolling are equally smooth, and that's where I did most of my testing (while replying to this ticket).

I now have a working standalone implementation of a wheel event filter that removes the horizontal component, leaving only vertical scrolling under touch event control while still allowing horizontal scrolling via the scrollbar.
See https://github.com/RJVB/wheelscrollfilter

For some reason this approach doesn't have the same effect in the ProjectTreeView class. I may have overlooked something trivial but either way I'd really appreciate the help of a fresh set of eyes to help pinpoint the cause of that difference.

rjvbb set the repository for this revision to R33 KDevPlatform.Jul 9 2017, 2:11 PM
rjvbb updated this revision to Diff 16386.Jul 9 2017, 2:27 PM

My bad, a hunk from a different local patch got included.

rjvbb updated this revision to Diff 16390.Jul 9 2017, 3:34 PM

This version works. Something is different between KDevPlatform's ProjectTreeView class and the QMimeTreeView class in my demonstrator which makes that in the former one has to do the event filtering at the level of the QTreeView *viewport*. That also works in my demonstrator, but isn't required there. I'd be curious to know why.

rjvbb set the repository for this revision to R33 KDevPlatform.Jul 9 2017, 3:35 PM
kfunk added a comment.Jul 9 2017, 10:47 PM

I really don't see myself looking forward to maintain this code/hack(?) in kdevplatform. Especially b/c it's just for one particular view.

Please fix it upstream in the item view classes if needed, but please let's not inject unnecessary #ifdef'fed code for macOS, code checking for widget styles or code altering the platform default behavior of a widget.

Still a -1 from me, I'd tend to think the other KDevelop core devs think alike (speak up if not).

Please fix it upstream in the item view classes if needed

In QTreeView? But there's nothing to fix in there...

Yes, it's all about a single toolview. As it happens, the other toolview showing comparable information (the Filesystem view) uses horizontal scrolling too. Without the filtering...

kfunk requested changes to this revision.Jul 10 2017, 9:57 PM
This revision now requires changes to proceed.Jul 10 2017, 9:57 PM
aaronpuchert added a comment.EditedJul 10 2017, 9:59 PM
In D6184#123281, @rjvbb wrote:

I'm beginning to understand the objections from X11 users. Even with my settings horizontal scrolling behaves as if it's configured to scroll at least half the viewport width at a time. On Mac/Cocoa, horizontal and vertical scrolling are equally smooth, and that's where I did most of my testing (while replying to this ticket).

For me it's not so much about smoothness. It's rather that scrolling in both directions happens with the same speed. That makes sense for images, but for scrolling through a directory tree you might want to have much less sensitive horizontal scrolling, while still being able to scroll fast vertically. I guess Mac OS does that. But this is not something we should try to fix in KDevelop.

In D6184#123507, @rjvbb wrote:

Yes, it's all about a single toolview. As it happens, the other toolview showing comparable information (the Filesystem view) uses horizontal scrolling too. Without the filtering...

Indeed, even the class view has horizontal scrolling. I'd say the case for elision is even stronger there, because that hierarchy isn't going to be very deep. (Though I don't know how deep people nest their name spaces...)

Another note: I was just using Thunderbird and noticed that they are eliding not at the end, but somewhere in the middle. Could this be a solution? Suppose you have files projectmanager.cpp and projectmanagerview.cpp, which are both abbreviated like projectmanag... right now. Instead we could abbreviate them proj...er.cpp and projec..ew.cpp. A disadvantage would be that we waste space for the file ending, which is already encoded in the icon to some extent.

@rjvbb Hi, please use the "Abandon this Revision" action, given that this patch/feature was not accepted, so the list of patches to review is not cluttered for everyone.

apol commandeered this revision.Jul 9 2019, 5:44 PM
apol abandoned this revision.
apol added a reviewer: rjvbb.