gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2019-06-03T01:08:37Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/594[RFE] More intelligent scrolling with touch devices or autoscrolling2019-06-03T01:08:37ZBugzilla[RFE] More intelligent scrolling with touch devices or autoscrolling## Submitted by Christian Stadelmann
Assigned to **gtk..@..tk.org**
**[Link to original bug (#760804)](https://bugzilla.gnome.org/show_bug.cgi?id=760804)**
## Description
This feature request affects:
* any scrolling feature with ...## Submitted by Christian Stadelmann
Assigned to **gtk..@..tk.org**
**[Link to original bug (#760804)](https://bugzilla.gnome.org/show_bug.cgi?id=760804)**
## Description
This feature request affects:
* any scrolling feature with touchpads (active edge, two-finger-scroll)
* scrolling with touchscreens
* scrolling using autoscroll (with middle mouse button)
* scrolling with a trackpoint (pointing stick)
This feature request doesn't affect:
* scrolling with scroll wheel
* keyboard buttons: arrow/page buttons
Current situation:
When scrolling with devices listed above, it is hard to exactly scroll vertically (or horizontally). In big documents on small screens you sometimes want to scroll exactly vertically (horizontally).
It would be useful to have scrolling with these devices changed in a way that if scroll events are put in a column (row) a threshold (e.g. an angle of 20°)
Typical applications include:
* zoomed in multi-column PDF documents where you want the column to start at a fixed position
* zoomed in websites
* large outputs in terminals, e.g. from syslog
* any table (in both text editors and applications) with more columns that a screen is able to display
Some software already supports this feature, including Opera 12.x series.
Version: 3.18.xhttps://gitlab.gnome.org/GNOME/gtk/-/issues/582Hard to click to move to top2018-09-01T15:39:25ZBugzillaHard to click to move to top## Submitted by Egmont Koblinger `@egmontkob`
Assigned to **gtk..@..tk.org**
**[Link to original bug (#757501)](https://bugzilla.gnome.org/show_bug.cgi?id=757501)**
## Description
Both the legacy and the overlay scrollbar:
If you...## Submitted by Egmont Koblinger `@egmontkob`
Assigned to **gtk..@..tk.org**
**[Link to original bug (#757501)](https://bugzilla.gnome.org/show_bug.cgi?id=757501)**
## Description
Both the legacy and the overlay scrollbar:
If you click in the scrollbar slot but not the actual scrollbar, the scrollbar's middle point is moved to the location of the click.
This is true for almost the entire height of the scrollbar slot, and also at the bottom the behavior is as close to this as possible. Supposing a 30px heigh scrollbar, if you click at the bottom 15px of the slot (not occupied by the draggable scrollbar at the moment), it'll be moved all the way to the very bottom.
This is, however, not true near the top. As you click close to the top, it's not the scrollbar's middle that moves to that point, but a point closer to the scrollbar's top.
This makes it very hard to move the contents to the very top. Basically you have to click exactly at the topmost pixel row of the scrollbar slot. Or drag the scrollbar.
Expected behavior: what happens at the bottom. Clicking near the top of the scrollbar slot (anywhere in the topmost 15px according to the previous example) should move the scrollbar to the very top.
(Ubuntu Wily, Gtk+ 3.16.7)
Version: 3.16.xhttps://gitlab.gnome.org/GNOME/gtk/-/issues/314Allow scroll wheel scrolling during DND2023-12-13T21:06:14ZBugzillaAllow scroll wheel scrolling during DND## Submitted by Nelson Benítez León `@nbenitez`
Assigned to **gtk..@..tk.org**
**[Link to original bug (#576952)](https://bugzilla.gnome.org/show_bug.cgi?id=576952)**
## Description
Please describe the problem:
Hi,
nautilus [bug 4...## Submitted by Nelson Benítez León `@nbenitez`
Assigned to **gtk..@..tk.org**
**[Link to original bug (#576952)](https://bugzilla.gnome.org/show_bug.cgi?id=576952)**
## Description
Please describe the problem:
Hi,
nautilus [bug 434193](https://bugzilla.gnome.org/show_bug.cgi?id=434193) wants to be able to scroll the destination window/folder when DND'ing a file in nautilus. This is currently not possible because gtk+ grabs keyboard when DND (see [bug 390312](https://bugzilla.gnome.org/show_bug.cgi?id=390312)), but although gtk grabs the scroll event on dnd, there's no reason why it should not resend it to the widget that is the drag destination.
That is what my patch does, listens to scroll events on DND and resend the event to the drag destination widget. For some limitations this only works when the source and destinations widgets belongs to same application, although could be different windows, like in the nautilus case.
I think this is good enough as it fullfils the nautilus use case which happens to be the most common.
Steps to reproduce:
1. Open two nautilus windows representing two folders, make sure second folder has enough files so the window has scrollbars.
2. Drag some file from first window to second window.
3. Now (without releasing the mouse button 1 and so dropping the file) use the mouse scrollwheel to scroll the second window content, so you can reach some unseen folder where to drop the file.
Actual results:
Nothing happens, mousewheel scroll events are ignored.
Expected results:
The nautilus window should receive the mouse wheel scroll events and thus scroll the content of the window.
Does this happen every time?
yes
Other information:
Version: 2.16.x
### Blocking
* [Bug 434193](https://bugzilla.gnome.org/show_bug.cgi?id=434193)