Community
Participate
Working Groups
Horizontal scroll bar in package explorer partially hides last item (if it reaches the bottom of the view) when user moves cursor (like trying to click on it) -- Configuration Details -- Product: Eclipse 4.7.0.20170620-1800 (org.eclipse.epp.package.rcp.product)Installed Features: org.eclipse.jdt 3.13.0.v20170612-0950 Versioning Plugin: org.eclipse.platform 4.7.0.v20170612-1255
Yes, selecting the last item in any list or tree can be tricky, if a horizontal scroll bar pops up. Is this a general GTK issue? S.t. Platform/UI can improve? Or SWT?
I have no issue with this on Windows 7.
(In reply to Dani Megert from comment #2) > I have no issue with this on Windows 7. I see it on Linux GTK all the time and in all views.
(In reply to Stephan Herrmann from comment #3) > (In reply to Dani Megert from comment #2) > > I have no issue with this on Windows 7. > > I see it on Linux GTK all the time and in all views. Which version of GTK are you using? GTK3.16+ uses overlay scrollbars, which should prevent this issue happening.
I have this issue in Gtk3.22 as well. The problem occurs if you move your mouse from the bottom up into a tree-view, trying to select the bottom item. I think the solution might be to move all items up and leave a small gap at the bottom to accommodate the scroll bar.
(In reply to Eric Williams from comment #4) > GTK3.16+ uses overlay scrollbars, which should prevent this issue happening. If "overlay scrollbars" is the concept of scrollbars popping up when the mouse reaches the margin, then it is the cause not the cure of the problem.
(In reply to Stephan Herrmann from comment #6) > (In reply to Eric Williams from comment #4) > > GTK3.16+ uses overlay scrollbars, which should prevent this issue happening. > > If "overlay scrollbars" is the concept of scrollbars popping up when the > mouse reaches the margin, then it is the cause not the cure of the problem. Ah yes I see what you mean now. I think it would be possible to implement something like in comment 5. I'll prepare a patch.
Fixing this issue isn't as trivial as it seems: The rendering mechanism for GtkTreeView is GtkCellRenderer. However renderers are attached by column, not by row. This means padding individual items/rows is tricky since any padding changes made to the renderer will apply to the whole tree. Unfortunately GTK CSS no longer exposes individual rows any more (as of 3.20) so that option isn't available either. I'm going to investigate the idea of making a "dummy" column, and then just keep track of the last item in the tree. That item will be attached to the dummy column, which allows for padding manipulation without altering the whole tree. This wiki touches upon it briefly: https://en.wikibooks.org/wiki/GTK%2B_By_Example/Tree_View/Columns_and_Renderers#How_to_Make_a_Whole_Row_Bold_or_Coloured Another option is to create a blank TreeItem to append to act as the padding and just keep it at the end of the tree. I'll continue to investigate.
(In reply to Eric Williams from comment #8) > Fixing this issue isn't as trivial as it seems: > > The rendering mechanism for GtkTreeView is GtkCellRenderer. However > renderers are attached by column, not by row. This means padding individual > items/rows is tricky since any padding changes made to the renderer will > apply to the whole tree. > > Unfortunately GTK CSS no longer exposes individual rows any more (as of > 3.20) so that option isn't available either. > > I'm going to investigate the idea of making a "dummy" column, and then just > keep track of the last item in the tree. That item will be attached to the > dummy column, which allows for padding manipulation without altering the > whole tree. > > This wiki touches upon it briefly: > https://en.wikibooks.org/wiki/GTK%2B_By_Example/Tree_View/ > Columns_and_Renderers#How_to_Make_a_Whole_Row_Bold_or_Coloured > > Another option is to create a blank TreeItem to append to act as the padding > and just keep it at the end of the tree. > > I'll continue to investigate. I'm currently working on bug 470031 full time so I am tossing this bug back into the pool. Current workaround: disable overlay scrolling fixes the issue. This can be accomplished by setting the GTK_OVERLAY_SCROLLING environment variable to 0. I.e.: export GTK_OVERLAY_SCROLLING=0 ./eclipse
(In reply to Eric Williams from comment #9) > Current workaround: disable overlay scrolling fixes the issue. This can be > accomplished by setting the GTK_OVERLAY_SCROLLING environment variable to 0. > > I.e.: > > export GTK_OVERLAY_SCROLLING=0 > ./eclipse I can confirm that this is an effective workaround. I'm not even sure that overlay scrollbars improve anything for me ;p so I might actually keep that setting ...
*** Bug 496828 has been marked as a duplicate of this bug. ***
*** Bug 479226 has been marked as a duplicate of this bug. ***
*** Bug 543990 has been marked as a duplicate of this bug. ***
If no fix is scheduled, I suggest to prominently recommend export GTK_OVERLAY_SCROLLING=0 in toplevel download / installation documentation. While looking for the proper location I wonder which is more suitable: https://www.eclipse.org/eclipse/development/readme_eclipse_4.10.php - not visible from https://www.eclipse.org/downloads/ https://wiki.eclipse.org/Eclipse/Installation - has no section for platform specific issues
(In reply to Stephan Herrmann from comment #14) > If no fix is scheduled, I suggest to prominently recommend > export GTK_OVERLAY_SCROLLING=0 > in toplevel download / installation documentation. > > While looking for the proper location I wonder which is more suitable: > > https://www.eclipse.org/eclipse/development/readme_eclipse_4.10.php > - not visible from https://www.eclipse.org/downloads/ > > https://wiki.eclipse.org/Eclipse/Installation > - has no section for platform specific issues I think I'll create a "known issues" section in the SWT wiki which I can point users to for cases like this.
(In reply to Eric Williams from comment #15) > (In reply to Stephan Herrmann from comment #14) > > If no fix is scheduled, I suggest to prominently recommend > > export GTK_OVERLAY_SCROLLING=0 > > in toplevel download / installation documentation. > > > > While looking for the proper location I wonder which is more suitable: > > > > https://www.eclipse.org/eclipse/development/readme_eclipse_4.10.php > > - not visible from https://www.eclipse.org/downloads/ > > > > https://wiki.eclipse.org/Eclipse/Installation > > - has no section for platform specific issues > > I think I'll create a "known issues" section in the SWT wiki which I can > point users to for cases like this. To have it in the wiki is a good start, but my idea was to pro-actively recommend this, rather than waiting for users to become frustrated.
*** Bug 551411 has been marked as a duplicate of this bug. ***
Actually, since recently (?) my workaround by disabling overlay scrolling no longer works: even a fixed / static horizontal can hide relevant content!! This, however, happens only sometimes, seen specifically, in the Git Staging view, and a little while later I could not reproduce. But I remember having seen this effect several times lately.
I actually prefer the proposed solution to add a blank TreeItem to append to as padding. The issue with GTK_OVERLAY_SCROLLING=0 is that: - Users may not know where to set this environment variable to. - Users may accidentally tweak and break their own custom GTK themes styles. - Users may accidentally disable the overlay scrolling across multiple user accounts, given that the online resources are not strongly recommending to only add this to Eclipse itself, but rather recommending it to be added as part of the profiles. - This flag may be subjected to changes in the Ubuntu upstream, particularly if Gnome4 will change the scrollbar behaviors again in some future.
There is an option to add some margin to the bottom of the StyledText/Tree in order to prevent this from happening. I'll look into it for 4.15 -- GNOME builder does it this way so we might be able to as well.
I didn't manage to get to this -- FWIW I think the margin solution is the way to go. I tried it once in GtkInspector and it fixed the issue, we just need to style the extra part (the margin) but I think that can also be done with some GTK CSS.
I can confirm the mentioned workaround works on a per application bases OS : OpenSuse 15.1 eclipse.buildId : 4.13.0.I20190916-1045 gtk3 version : 3.22.30 Workaround: Launch eclipse as GTK_OVERLAY_SCROLLING=0 <path to eclipse>/eclipse
Credit for comment 22. Workaround taken from http://ubuntuhandbook.org/index.php/2019/09/make-scrollbar-always-visible-ubuntu-18-04/
Created attachment 283136 [details] Bottom margin on treeview Looking to pick up where this was left off. I have been trying to file alternatives to adding a margin to all Scrollable components. I have tried overwritting the page size so the vertical scroll is larger by a bit, but wasn't successful. I added a screenshot of what the margin would look. The problem with this is that it doesn't look very nice.
To comment #24 What if you just add an extra child element to the Scrollable component, instead of margins? This extra child element can be disabled, so no clickable events will occur.
