gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2024-03-02T10:11:36Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/6237ScrolledWindow's overshoot and undershoot are not RTL-friendly2024-03-02T10:11:36ZPeter EisenmannScrolledWindow's overshoot and undershoot are not RTL-friendlyThe overshoot and undershoot of `GtkScrolledWindow` have fixed CSS classes that are not dependent on RTL settings. So it is not possible to add styles for one specific side, as it would break when changing the RTL setting.The overshoot and undershoot of `GtkScrolledWindow` have fixed CSS classes that are not dependent on RTL settings. So it is not possible to add styles for one specific side, as it would break when changing the RTL setting.https://gitlab.gnome.org/GNOME/gtk/-/issues/6434GtkScrolledWindow scrolls in the wrong direction2024-02-15T13:21:31ZMischa BaarsGtkScrolledWindow scrolls in the wrong directionHi,
Yesterday I made a start updating some of my code, such that it uses GtkColumnView instead of GtkTreeView. After adding a couple of GtkColumnViewColumns, I noticed that the GtkScrolledWindow was refusing to scroll in the right direc...Hi,
Yesterday I made a start updating some of my code, such that it uses GtkColumnView instead of GtkTreeView. After adding a couple of GtkColumnViewColumns, I noticed that the GtkScrolledWindow was refusing to scroll in the right direction.
I have attached the code. The gtk_builder_00.ui file contains the GtkWindow's default-width ranges for which this phenomenon occurs given the 16 GtkColumnViewColumns. When using Adwaita the problem is more severe than without.
You can change the GTK version in the makefile.
Best regards,
Mischa Baars.
[2024021300_gtkbug.tar.xz](/uploads/18286da414ca53f208fb50590902ef15/2024021300_gtkbug.tar.xz)https://gitlab.gnome.org/GNOME/gtk/-/issues/1408Handling of lines to scroll setting on win322024-01-13T22:22:13ZLukas K.Handling of lines to scroll setting on win32359df028be7b1dae76a1abb9bad8a3b86a648765 introduced multiplying smooth scroll deltas by `SPI_GETWHEELSCROLL_LINES` on win32. While this makes actual scrolling of widgets contained in a GtkScrolledWindow behave as intended by the platform...359df028be7b1dae76a1abb9bad8a3b86a648765 introduced multiplying smooth scroll deltas by `SPI_GETWHEELSCROLL_LINES` on win32. While this makes actual scrolling of widgets contained in a GtkScrolledWindow behave as intended by the platform, this also affects widgets that use the mouse wheel for zooming as in the zoom factor per scroll wheel click now depends on the 'how many lines to scroll' settings. This is clearly not intended since a non-exhaustive investigation found no other win32 apps change their zoom increments based on that setting.
Suggested solution:
- Don't multiply in the win32 backend
- Add a method to gdk that finds out how many lines to scroll per scroll wheel click. Most likely, this method will just return 1 on all backends but win32.
- Use said method in https://gitlab.gnome.org/GNOME/gtk/blob/master/gtk/gtkscrolledwindow.c#L1133https://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)https://gitlab.gnome.org/GNOME/gtk/-/issues/1997Scrolling from a touchscreen is a bit slow2023-11-19T17:20:03ZAdrien PlazasScrolling from a touchscreen is a bit slowKinetic scrolling from a touchpad works well, however from a touchscreen it feels a bit slow. I suggest we use a deceleration friction of 1 (instead of 4) when the scrolling event comes from a touch screen.
I tested this in GTK 3 by ope...Kinetic scrolling from a touchpad works well, however from a touchscreen it feels a bit slow. I suggest we use a deceleration friction of 1 (instead of 4) when the scrolling event comes from a touch screen.
I tested this in GTK 3 by opening Files in `/usr`, by searching `lib`, and by scrolling from a touchpad or a touchscreen.https://gitlab.gnome.org/GNOME/gtk/-/issues/4477CRITICAL: gtk_scrolled_window_start_deceleration: assertion 'priv->decelerati...2023-10-19T10:54:02Zalex-teeCRITICAL: gtk_scrolled_window_start_deceleration: assertion 'priv->deceleration_id == 0' failed when scrolling in a popover menu## Steps to reproduce
Not sure, I just right clicked somewhere to show a popover menu and then I scrolled (see screenshot below)
## Current behavior
I got this CRITICAL message
## Expected outcome
No CRITICAL message
## Version inform...## Steps to reproduce
Not sure, I just right clicked somewhere to show a popover menu and then I scrolled (see screenshot below)
## Current behavior
I got this CRITICAL message
## Expected outcome
No CRITICAL message
## Version information
031aab3ef6633dbea1ead675b0dbdbf562efe5ee as subproject, Arch Linux
## Additional information
backtrace
```
(zrythm:905270): Gtk-CRITICAL **: 11:33:06.660: ((null):(null)): gtk_scrolled_window_start_deceleration: assertion 'priv->deceleration_id == 0' failed
Thread 1 "zrythm" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff715892b in g_logv () from /usr/lib/libglib-2.0.so.0
(gdb) bt full
#0 0x00007ffff715892b in g_logv () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff7158c00 in g_log () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff77660ff in gtk_scrolled_window_start_deceleration (scrolled_window=0x5555856c6fa0) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkscrolledwindow.c:3328
priv = 0x5555856c6c90
frame_clock = 0x0
current_time = 0
elapsed = 4.6356104007821874e-310
__func__ = "gtk_scrolled_window_start_deceleration"
#3 0x00007ffff775f6b7 in gtk_scrolled_window_decelerate (scrolled_window=0x5555856c6fa0, x_velocity=0, y_velocity=0) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkscrolledwindow.c:1055
priv = 0x5555856c6c90
overshoot = 1
#4 0x00007ffff77604f4 in scroll_controller_decelerate (scroll=0x5555856ec760, initial_vel_x=0, initial_vel_y=0, scrolled_window=0x5555856c6fa0) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkscrolledwindow.c:1470
unit_x = 35.665890259784945
unit_y = 38.619575384225179
shifted = 0
state = (unknown: 0x10)
#5 0x00007ffff7541972 in _gtk_marshal_VOID__DOUBLE_DOUBLEv (closure=0x55558533e7d0, return_value=0x0, instance=0x5555856ec760, args=0x7fffffffd010, marshal_data=0x0, n_params=2, param_types=0x5555833a3da0)
at subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkmarshalers.c:4147
cc = 0x55558533e7d0
data1 = 0x5555856ec760
data2 = 0x5555856c6fa0
callback = 0x7ffff776040f <scroll_controller_decelerate>
arg0 = 0
arg1 = 0
args_copy = {{
gp_offset = 24,
fp_offset = 80,
overflow_arg_area = 0x7fffffffd0f0,
reg_save_area = 0x7fffffffd030
}}
#6 0x00007ffff72621c0 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#7 0x00007ffff7262330 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#8 0x00007ffff7632886 in gtk_event_controller_scroll_handle_event (controller=0x5555856ec760, event=0x55558b51f180, x=0, y=0) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkeventcontrollerscroll.c:346
vel_x = 0
vel_y = 0
scroll = 0x5555856ec760
direction = GDK_SCROLL_SMOOTH
dx = 0
dy = 0
handled = 0
__func__ = "gtk_event_controller_scroll_handle_event"
#9 0x00007ffff762f26b in gtk_event_controller_handle_event (controller=0x5555856ec760, event=0x55558b51f180, target=0x55558b707b00, x=0, y=0) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkeventcontroller.c:369
controller_class = 0x5555833a3a60
priv = 0x5555856ec730
retval = 0
__func__ = "gtk_event_controller_handle_event"
#10 0x00007ffff786f940 in gtk_widget_run_controllers (widget=0x5555856c6fa0, event=0x55558b51f180, target=0x55558b707b00, x=0, y=0, phase=GTK_PHASE_CAPTURE)
--Type <RET> for more, q to quit, c to continue without paging--c
at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkwidget.c:4562
this_handled = -2093506992
is_gesture = 0
controller_phase = GTK_PHASE_CAPTURE
next = 0x55558552d180 = {0x5555856ec6f0, 0x5555856e88d0, 0x5555856e9530, 0x55558540fa20, 0x5555856e9460, 0x5555856db530, 0x5555856ec200}
priv = 0x5555856c6e50
controller = 0x5555856ec760
handled = 0
l = 0x55558552d1a0 = {0x5555856ec760, 0x5555856ec6f0, 0x5555856e88d0, 0x5555856e9530, 0x55558540fa20, 0x5555856e9460, 0x5555856db530, 0x5555856ec200}
__func__ = "gtk_widget_run_controllers"
#11 0x00007ffff786fecd in _gtk_widget_captured_event (widget=0x5555856c6fa0, event=0x55558b51f180, target=0x55558b707b00) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkwidget.c:4725
return_val = 0
x = 0
y = 0
__func__ = "_gtk_widget_captured_event"
#12 0x00007ffff76e140c in gtk_propagate_event_internal (widget=0x5555856c6fa0, event=0x55558b51f180, topmost=0x55558526ef80) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkmain.c:1878
handled_event = 0
target = 0x55558b707b00
widget_array = {
start = 0x7fffffffd338,
end = 0x7fffffffd388,
end_allocation = 0x7fffffffd3b8,
preallocated = {0x55558b707b00, 0x55558b7707e0, 0x55558ac88bb0, 0x55558b770360, 0x55558ba77760, 0x5555856e4f80, 0x5555856f03c0, 0x5555856c6fa0, 0x5555856ca430, 0x55558526ef80, 0x2, 0x7fffffffd760, 0x7ffff789533d, 0x18526af50, 0x555583155650, 0x555585096330}
}
i = 7
#13 0x00007ffff76e169c in gtk_propagate_event (widget=0x55558b707b00, event=0x55558b51f180) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkmain.c:1960
window_group = 0x555583155650
event_widget = 0x55558526ef80
topmost = 0x55558526ef80
__func__ = "gtk_propagate_event"
#14 0x00007ffff76e0e00 in gtk_main_do_event (event=0x55558b51f180) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkmain.c:1652
event_widget = 0x55558526ef80
target_widget = 0x55558b707b00
grab_widget = 0x55558b707b00
window_group = 0x555583155650
rewritten_event = 0x0
tmp_list = Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x6f6c63007463656a
#15 0x00007ffff7722954 in surface_event (surface=0x555583379e50, event=0x55558b51f180, widget=0x55558526ef80) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gtk/gtkpopover.c:827
#16 0x00007ffff79d4ee0 in _gdk_marshal_BOOLEAN__POINTER (closure=0x55558b55dff0, return_value=0x7fffffffd700, n_param_values=2, param_values=0x7fffffffd760, invocation_hint=0x7fffffffd6e0, marshal_data=0x0) at subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gdk/gdkmarshalers.c:258
cc = 0x55558b55dff0
data1 = 0x555583379e50
data2 = 0x55558526ef80
callback = 0x7ffff7722934 <surface_event>
v_return = 21845
__func__ = "_gdk_marshal_BOOLEAN__POINTER"
#17 0x00007ffff7a13081 in gdk_surface_event_marshaller (closure=0x55558b55dff0, return_value=0x7fffffffd700, n_param_values=2, param_values=0x7fffffffd760, invocation_hint=0x7fffffffd6e0, marshal_data=0x0) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gdk/gdksurface.c:435
event = 0x55558b51f180
#18 0x00007ffff7244d8f in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff7260718 in () at /usr/lib/libgobject-2.0.so.0
#20 0x00007ffff726140b in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#21 0x00007ffff7262330 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff7a18143 in gdk_surface_handle_event (event=0x55558b51f180) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gdk/gdksurface.c:2948
surface = 0x555583379e50
begin_time = 0
handled = 0
#23 0x00007ffff79f3392 in _gdk_event_emit (event=0x55558b51f180) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gdk/gdkevents.c:490
#24 0x00007ffff7a7ccf1 in gdk_event_source_dispatch (source=0x555582800fb0, callback=0x0, user_data=0x0) at ../subprojects/gtk-031aab3ef6633dbea1ead675b0dbdbf562efe5ee/gdk/x11/gdkeventsource.c:425
display = 0x5555827eb030
event = 0x55558b51f180
#25 0x00007ffff71504dc in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#26 0x00007ffff71a4799 in () at /usr/lib/libglib-2.0.so.0
#27 0x00007ffff714dbc1 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#28 0x00007ffff73632fe in g_application_run () at /usr/lib/libgio-2.0.so.0
#29 0x0000555555e9e31c in main(int, char**) (argc=2, argv=0x7fffffffdd28) at ../src/main.c:42
ret = 0
```
screenshot when this happened
![Screenshot_from_2021-11-22_11-33-53](/uploads/d31137c0ab07e640cb0f562adcb5aa46/Screenshot_from_2021-11-22_11-33-53.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/2723Gestures inside GtkScrolledWindow not activating2023-10-16T07:55:24ZlehmanjuGestures inside GtkScrolledWindow not activating## Steps to reproduce
1. Add a scrolled window inside a scrolled window
2. Use touchscreen to activate pan gesture
## Current behavior
Top most scrolled window reacts to gesture, child scrolled window doesn't get notified at all.
##...## Steps to reproduce
1. Add a scrolled window inside a scrolled window
2. Use touchscreen to activate pan gesture
## Current behavior
Top most scrolled window reacts to gesture, child scrolled window doesn't get notified at all.
## Expected outcome
Bottom most scrolled window (or any other widget that registers to this gesture) should receive the gesture.
## Version information
GTK3 and GTK4
## Additional information
I believe containers should be using BUBBLE_PHASE instead of CAPTURE_PHASE for event controllers. Specifically if I want to use gestures on a child widget inside a scrolled window (e.g. drag gesture) events get eaten by the parent container. However, this shouldn't happen as child widgets then don't behave correctly anymore. Instead, containers should behave as any other widget regarding gestures.
With `gtk_widget_observe_controllers` it should be possible to achieve the current behavior again, however, I think scrolled window should default to BUBBLE_PHASE.https://gitlab.gnome.org/GNOME/gtk/-/issues/5882scrolling mishandled during focus changes2023-06-12T15:40:10ZRafał Mużyłoscrolling mishandled during focus changesI'm not sure if all of the elements mentioned below are necessary to trigger the bug; in fact, I expect most aren't, but still mentioning them all.
So, the hierarchy first: Listbox > ScrolledWindow > Box > Stack > Box > Window.
My wind...I'm not sure if all of the elements mentioned below are necessary to trigger the bug; in fact, I expect most aren't, but still mentioning them all.
So, the hierarchy first: Listbox > ScrolledWindow > Box > Stack > Box > Window.
My window manager is set to 'focus-follows-mouse'.
So, I start a ruby-gtk4 script in a terminal, that shows a gui (gui hierarchy is somewhat convoluted, due to my desire to keep things simple as I was writing it). I move the mouse back to the terminal. `^Z; bg <task id>`. I get to that listbox, that has been filled with a lengthy list of elements. I pick one of them.
I get back to the terminal. I run a command that has multiple lines of output, that I redirect into `less`.
I scroll for a bit through that content using mouse wheel.
Now for the bug.
After that bit of scrolling I move the mouse back into gui. I attempt to scroll the listbox with the wheel a little bit more.
Now, what happens, is the listbox gets scrolled a *huge* amount. I haven't checked the numbers, but I strongly suspect all the scrolling in the terminal gets duplicated into the listbox.
Well, that's pretty much it.
On unrelated note, quite often while running that script I get output like `gtk_css_node_insert_after: assertion 'previous_sibling == NULL || previous_sibling->parent == parent' failed` or `Trying to snapshot GtkGizmo 0x55f43a168c00 without a current allocation`, Any ideas what could be causing those ? After I've initialized the gui, I'm not doing any hierarchy changes or adding/removing widgets...https://gitlab.gnome.org/GNOME/gtk/-/issues/210GTK 3.22 scrollbar errors when resizing GtkTextView in a GtkScrolledWindow2023-02-13T11:52:31ZSimeon AndreevGTK 3.22 scrollbar errors when resizing GtkTextView in a GtkScrolledWindowTo reproduce, run snippet: [text_scrollbar_errors.cpp](/uploads/73409713404e7d556caa2a5633ed4923/text_scrollbar_errors.cpp)
Then shrink the window to its minimum size, observe multiple GTK errors on standard error:
`
(TextScrollbarErro...To reproduce, run snippet: [text_scrollbar_errors.cpp](/uploads/73409713404e7d556caa2a5633ed4923/text_scrollbar_errors.cpp)
Then shrink the window to its minimum size, observe multiple GTK errors on standard error:
`
(TextScrollbarErrors:23242): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
`
See demo: ![scrollbar_errors_on_resize](/uploads/eaaabdae64b9df51e3067727cf8b3aec/scrollbar_errors_on_resize.gif)
I see this with:
RHEL 7.4
default Adwaita theme
gtk3-3.22.10-4.el7.x86_64
Originally we observed this in multiple parts of Eclipse 4.x.https://gitlab.gnome.org/GNOME/gtk/-/issues/5565macOS Ventura ARM chip: PolicyType::Always doesn't work2023-02-03T10:26:55ZGhost UsermacOS Ventura ARM chip: PolicyType::Always doesn't workgtk: `4.9.3`
mac: `Apple M1 Pro`
os: `Ventura 13.1 (22C65)`
I set the `set_policy` of the scroll window to `gtk::PolicyType::Always`, but the scrollbar is not always visible.
Please watch the video attached.
![scroll-ba...gtk: `4.9.3`
mac: `Apple M1 Pro`
os: `Ventura 13.1 (22C65)`
I set the `set_policy` of the scroll window to `gtk::PolicyType::Always`, but the scrollbar is not always visible.
Please watch the video attached.
![scroll-bar](/uploads/9b0e1fb5ac6b3b145399bbdbbf59e145/scroll-bar.mp4)
```
fn build_ui(app: >k::Application) {
let window = gtk::ApplicationWindow::new(app);
window.set_size_request(200, 200);
let pic1 = gtk::Picture::for_filename("b.jpg");
pic1.set_can_shrink(false);
let pic1_scrolled_window = gtk::ScrolledWindow::new();
pic1_scrolled_window.set_policy(gtk::PolicyType::Always, gtk::PolicyType::Always);
pic1_scrolled_window.set_child(Some(&pic1));
window.set_child(Some(&pic1_scrolled_window));
window.show();
}
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5151Horizontal mouse wheel scroll is inverted2022-09-18T00:12:56ZFrank BrüttingHorizontal mouse wheel scroll is inverted# System information #
Fedora 36
What is the version of GNOME Text Editor?
42.2
```
Text Editor (42.2)
Flatpak: yes
GLib: 2.72.3 (2.72.2)
GTK: 4.6.6 (4.6.5)
GtkSourceView: 5.4.2 (5.4.1)
Libadwaita: 1.1.4 (1.1.2)
Enchant2: 2.2.15
gtk-...# System information #
Fedora 36
What is the version of GNOME Text Editor?
42.2
```
Text Editor (42.2)
Flatpak: yes
GLib: 2.72.3 (2.72.2)
GTK: 4.6.6 (4.6.5)
GtkSourceView: 5.4.2 (5.4.1)
Libadwaita: 1.1.4 (1.1.2)
Enchant2: 2.2.15
gtk-theme-name: Adwaita-empty
GTK_THEME: unset
org.gnome.TextEditor restore-session = true
org.gnome.TextEditor recolor-window = true
org.gnome.TextEditor show-map = false
org.gnome.TextEditor custom-font = 'Monospace 11'
org.gnome.TextEditor show-line-numbers = false
org.gnome.TextEditor style-scheme = 'solarized-dark' [default='Adwaita']
org.gnome.TextEditor wrap-text = false [default=true]
org.gnome.TextEditor style-variant = 'follow'
org.gnome.TextEditor indent-style = 'tab'
org.gnome.TextEditor show-right-margin = false
org.gnome.TextEditor spellcheck = false [default=true]
org.gnome.TextEditor auto-indent = true
org.gnome.TextEditor use-system-font = true
org.gnome.TextEditor keybindings = 'default'
org.gnome.TextEditor highlight-current-line = false
org.gnome.TextEditor last-save-directory = ''
org.gnome.TextEditor auto-save-delay = uint32 3
org.gnome.TextEditor discover-settings = true
org.gnome.TextEditor enable-snippets = false
org.gnome.TextEditor line-height = 1.2
org.gnome.TextEditor indent-width = -1
org.gnome.TextEditor show-grid = false
org.gnome.TextEditor draw-spaces = @as []
org.gnome.TextEditor right-margin-position = uint32 100 [default=uint32 80]
org.gnome.TextEditor tab-width = uint32 4 [default=uint32 8]
```
Have you tested Nightly to see if the issue has been fixed? If not, why?
Yes, it’s the same wrong behavior there.
# Bug information #
Just scroll horizontally.
## Current behaviour ##
Horizontal mouse wheel scroll is inverted, both in default as in natural scrolling mode.
## Expected behaviour ##
Identical scroll direction as in all other applications.https://gitlab.gnome.org/GNOME/gtk/-/issues/1079Kinetic scrolling overshoot is triggered when lifting the fingers from the to...2022-07-30T18:15:08ZElia GerettoKinetic scrolling overshoot is triggered when lifting the fingers from the touchpad, while keeping them still## Steps to reproduce
1. Open an application that uses a GtkScrolledWindow, e.g. Evince.
2. Scroll the view using two-fingers scroll or edge scroll.
3. Stop moving your fingers, but keep them on the touchpad.
4. Lift the fingers.
<...## Steps to reproduce
1. Open an application that uses a GtkScrolledWindow, e.g. Evince.
2. Scroll the view using two-fingers scroll or edge scroll.
3. Stop moving your fingers, but keep them on the touchpad.
4. Lift the fingers.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example that
exhibits the issue.
-->
## Current behavior
I define minimum scroll events as the libinput scroll events generated when moving the fingers on the touchpad as slow as possible.
If the touchpad generates one or two spurious events when lifting the fingers, on a touchpad that produces a minimum scroll event of 1.46 points, overshoot is triggered. This makes the view bounce away from where it was placed before lifting the fingers.
## Expected outcome
The spurious events generated when lifting the fingers should be ignored, or trigger a simple deceleration, making the view stay close to where it was placed.
## Version information
GTK+ 3.22.26 on Fedora 27.
## Additional information
This is the libinput debug-events output when reproducing the problem:
```
event6 POINTER_AXIS +1.02s vert -3.16* horiz 0.24* (finger)
event6 POINTER_AXIS +1.03s vert -3.16* horiz 0.00 (finger)
event6 POINTER_AXIS +1.05s vert -2.91* horiz -0.24* (finger)
event6 POINTER_AXIS +1.06s vert -3.16* horiz -0.24* (finger)
event6 POINTER_AXIS +1.07s vert -3.89* horiz -0.24* (finger)
event6 POINTER_AXIS +1.09s vert -4.13* horiz 0.00 (finger)
event6 POINTER_AXIS +1.10s vert -4.37* horiz 0.00 (finger)
event6 POINTER_AXIS +1.11s vert -4.86* horiz 0.24* (finger)
event6 POINTER_AXIS +1.12s vert -5.83* horiz 0.24* (finger)
event6 POINTER_AXIS +1.14s vert -6.07* horiz 0.47* (finger)
event6 POINTER_AXIS +1.15s vert -2.19* horiz 0.47* (finger)
event6 POINTER_AXIS +1.16s vert -7.77* horiz 1.18* (finger)
event6 POINTER_AXIS +1.18s vert -7.04* horiz 1.18* (finger)
event6 POINTER_AXIS +1.19s vert -6.32* horiz 1.18* (finger)
event6 POINTER_AXIS +1.20s vert -4.62* horiz 0.71* (finger)
event6 POINTER_AXIS +1.21s vert -5.59* horiz 0.94* (finger)
event6 POINTER_AXIS +1.23s vert -3.89* horiz 0.71* (finger)
event6 POINTER_AXIS +1.24s vert -4.62* horiz 1.18* (finger)
event6 POINTER_AXIS +1.25s vert -4.62* horiz 1.18* (finger)
event6 POINTER_AXIS +1.27s vert -3.64* horiz 0.47* (finger)
event6 POINTER_AXIS +1.28s vert -1.94* horiz 0.24* (finger)
event6 POINTER_AXIS +1.29s vert -3.89* horiz 0.24* (finger)
event6 POINTER_AXIS +1.30s vert -1.46* horiz 0.00 (finger)
event6 POINTER_AXIS +1.32s vert -1.46* horiz 0.00 (finger)
event6 POINTER_AXIS +1.33s vert -1.46* horiz 0.00 (finger)
event6 POINTER_AXIS +1.50s vert -0.49* horiz -1.41* (finger)
event6 POINTER_AXIS +1.81s vert 3.64* horiz -2.12* (finger)
event6 POINTER_AXIS +1.82s vert 0.00* horiz 0.00* (finger)
```
The one before the last event is a spurious event, generated by my touchpad while lifting my fingers at the end of the scroll.
This issue is reproducible on my laptop, an ASUS N550JV, but it is not reproducible on other laptops, like an XPS 13. The main reason seems to be that, in the case of the XPS 13, the minimum scroll event is 0.61, so spurious events are never higher than 1. This is probably due to different touchpad resolutions.https://gitlab.gnome.org/GNOME/gtk/-/issues/3515ScrolledWindow doesn't expand with TextView according to max_content_height2021-04-18T15:15:38ZMateusz KumięgaScrolledWindow doesn't expand with TextView according to max_content_height## Steps to reproduce
1. Put `TextView` in `ScrolledWindow` and then into `Layout`.
2. Set some `max-content-height` on `ScrolledWindow`.
3. Run the application. Type multiple lines into `TextView` so that text doesn't fit into origi...## Steps to reproduce
1. Put `TextView` in `ScrolledWindow` and then into `Layout`.
2. Set some `max-content-height` on `ScrolledWindow`.
3. Run the application. Type multiple lines into `TextView` so that text doesn't fit into originally sized widget.
## Current behavior
1. When `ScrolledWindow` has vertical scroll policy set to AUTO, then it never expands beyond its original size and shows scrollbars as soon as the `TextView` doesn't fit.
2. When `ScrolledWindow` has vertical scroll policy set to NEVER, then it always expands, but sometimes not enough for the line of text to fit. This results in the text cursor being placed above unusable blank area.
## Expected outcome
1. When `ScrolledWindow` has vertical scroll policy set to AUTO, then it should expand up to `max-content-height` and then show scrollbars.
2. When `ScrolledWindow` has vertical scroll policy set to NEVER, then it should expand so that new line of text is always at the bottom.
## Version information
GTK 3.24.24
Debian Linux
## Additional information
Attached a simple Glade file that demonstrates two cases and a `TextView` outside of `ScrolledWindow` for comparison. Also attached a screen recording.
I created a StackOverflow question (https://stackoverflow.com/questions/65449889/gtk-scrolledwindow-max-content-width-height-does-not-work-with-textview), but now I believe this is a bug (or two separate bugs), so I decided to report it here too.
![gtk_scrolledwindow_expand](/uploads/fde80ff42a67221518d7a1e750583616/gtk_scrolledwindow_expand.mp4)[gtk_scrolledwindow_expand.glade](/uploads/978307a5b402727a6c1c7e81d901c45f/gtk_scrolledwindow_expand.glade)https://gitlab.gnome.org/GNOME/gtk/-/issues/1625Support scrollTo, scrollToPoint, scrollSubstringTo, scrollSubstringToPoint2021-01-04T15:15:40ZSamuel ThibaultSupport scrollTo, scrollToPoint, scrollSubstringTo, scrollSubstringToPointHello,
AT-SPI got enriched with IA2-inspired scrollTo, scrollToPoint, scrollSubstringTo, scrollSubstringToPoint interfaces, which allow an AT tool to request that a given part of the GUI becomes visible by scrolling whatever is needed t...Hello,
AT-SPI got enriched with IA2-inspired scrollTo, scrollToPoint, scrollSubstringTo, scrollSubstringToPoint interfaces, which allow an AT tool to request that a given part of the GUI becomes visible by scrolling whatever is needed to scroll to make it visible.
scrollTo and scrollToPoint can be used on any AtkComponent, and whatever scrollable parent needs to be scrolled to bring it into view.
scrollSubstringTo and scrollSubstringToPoint can be used on AtkText only, to bring a piece of text into view, they can probably be relatively easy to implement for text viewers (but in principle the textviewer itself would need to be brought into view)
Samuelhttps://gitlab.gnome.org/GNOME/gtk/-/issues/809Bottom scroll bar goes on top of final line2020-08-15T16:23:03ZBugzillaBottom scroll bar goes on top of final line## Submitted by coo..@..il.com
Assigned to **Gedit maintainers**
**[Link to original bug (#781669)](https://bugzilla.gnome.org/show_bug.cgi?id=781669)**
## Description
I am on Arch Linux with GNOME 3.24.1, though obviously still G...## Submitted by coo..@..il.com
Assigned to **Gedit maintainers**
**[Link to original bug (#781669)](https://bugzilla.gnome.org/show_bug.cgi?id=781669)**
## Description
I am on Arch Linux with GNOME 3.24.1, though obviously still Gedit 3.22.0, and I have found something slightly annoying with it, and that is that when mousing over the last line to try to copy and paste it for instance, the bottom scroll bar goes on top of it and obscures it. I have attached two screenshots of what I mean.
Version: 3.22.xhttps://gitlab.gnome.org/GNOME/gtk/-/issues/1146Fix wheel scrolling for very small adjustment page_size2020-07-10T10:26:12ZMichael NattererFix wheel scrolling for very small adjustment page_sizeFor very small page sizes of < 1.0, the effect of pow() is the
opposite of what's intended and the scroll steps become unusably
large, make sure we never get a scroll_unit larger than page_size /
2.0, which used to be the default before ...For very small page sizes of < 1.0, the effect of pow() is the
opposite of what's intended and the scroll steps become unusably
large, make sure we never get a scroll_unit larger than page_size /
2.0, which used to be the default before the pow() magic was
introduced.
[0001-gtk-fix-wheel-scrolling-for-very-small-adjustment-pa.patch](/uploads/a42c531736041d4813712ebe20ddaa7b/0001-gtk-fix-wheel-scrolling-for-very-small-adjustment-pa.patch)https://gitlab.gnome.org/GNOME/gtk/-/issues/695Enable scrolling more quickly or precisely2020-07-10T10:26:12ZBugzillaEnable scrolling more quickly or precisely## Submitted by swo..@..ol.com
**[Link to original bug (#773618)](https://bugzilla.gnome.org/show_bug.cgi?id=773618)**
## Description
On using scrollbars I'm noticing that they are not utilizing their full potential if they have to ...## Submitted by swo..@..ol.com
**[Link to original bug (#773618)](https://bugzilla.gnome.org/show_bug.cgi?id=773618)**
## Description
On using scrollbars I'm noticing that they are not utilizing their full potential if they have to handle large documents and maybe this can be enhanced:
- I'm noticing that there is a minor scroll acceleration for example if the scrollwheel is moved fast (not sure if this comes from SciTE or GTK+). If missing this feature could be implemented directly and in either case I think it should be more aggressive at default.
- Scrolling on the scrollbar (hovering the mouse over it and using the scrollwheel) acts like the above except that larger steps for scrolling are used but this is still not enough on large documents. In case this is a SciTE-specific feature it could be implemented directly too and in either case the accelerating here should maybe switch to percent based scrolling (like 1% steps) on high accelerations to allow a fast but precise scrolling through these documents.
- Steppers (if enabled) have no short pause after being clicked before they automatically activate autorepeat. This makes it hard for pixel-perfect scrolling on a click.
Also these enhancements could be bind to settings in case users want to justify their behavior.
Version: 3.22.x
### See also
* [Bug 609335](https://bugzilla.gnome.org/show_bug.cgi?id=609335)
* [Bug 734397](https://bugzilla.gnome.org/show_bug.cgi?id=734397)https://gitlab.gnome.org/GNOME/gtk/-/issues/187Kinetic scrolling in GtkScrolledWindow should be cancelled when setting its a...2020-04-18T23:06:38ZMichael GrattonKinetic scrolling in GtkScrolledWindow should be cancelled when setting its adjustment's value## Steps to reproduce
1. Start scrolling a GtkScrolledWindow with a kinetic device (touchscreen, trackpad, etc)
2. Call `gtk_adjustment_set_value()` or similar on the GtkScrolledWindow's adjustment while the scroll gesture still has s...## Steps to reproduce
1. Start scrolling a GtkScrolledWindow with a kinetic device (touchscreen, trackpad, etc)
2. Call `gtk_adjustment_set_value()` or similar on the GtkScrolledWindow's adjustment while the scroll gesture still has some momentum, i.e. while the overlay scrollbars are still visible
## Current behavior
The child widget is scrolled to the requested position, then jumps and keeps on scrolling as the kinetic scroll kicks back in again.
## Expected outcome
The child widget is scrolled to the requested position, and stays there.
## Version information
GTK+ 3.22.29 (Ubuntu package: 3.22.29-3ubuntu1)
## Additional information
A work around is to call `gtk_scrolled_window_set_kinetic_scrolling(false)`, then set the adjustement's value, then call `gtk_scrolled_window_set_kinetic_scrolling(true)` again.
This was noticed when [trying to track down](https://mail.gnome.org/archives/gtk-app-devel-list/2018-April/msg00011.html) why scrolling to a newly inserted row in GtkListBox was sometimes not being scrolled to for [Geary Bug 778027](https://bugzilla.gnome.org/show_bug.cgi?id=778027).https://gitlab.gnome.org/GNOME/gtk/-/issues/2247Clicking should stop scroll2019-11-18T12:25:28ZRaffaeleClicking should stop scrollCurrently, clicking or selecting another item with the arrow keys while scrolling through a GtkListBox (e.g. the Permissions one from g-c-c) does not stop the scrolling action, which is kind of inconsistent with the expected physical beh...Currently, clicking or selecting another item with the arrow keys while scrolling through a GtkListBox (e.g. the Permissions one from g-c-c) does not stop the scrolling action, which is kind of inconsistent with the expected physical behaviour.https://gitlab.gnome.org/GNOME/gtk/-/issues/2229Keep cursor scrolling when ScrollArea limit is reached2019-11-18T12:25:03ZRaffaeleKeep cursor scrolling when ScrollArea limit is reachedStarting a two-finger swipe on a touchpad while focusing a scrollable area triggers a scrolling action which is not cancellable until fingers are removed from the touchpad.
However, the "scrolling" cursor returns for some moments to a no...Starting a two-finger swipe on a touchpad while focusing a scrollable area triggers a scrolling action which is not cancellable until fingers are removed from the touchpad.
However, the "scrolling" cursor returns for some moments to a normal one once the limit of the scroll area is reached, resulting in a weird high-frequency cursor switching "glitch". Keeping the cursor to the "scrolling" one also in this case (so until the scrolling is over/fingers leave touchpad) should be fine given that there is already a visual hint (the drop-shadow on the end side) for the end of the scrolling area.