gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2023-11-19T17:24:25Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/3435Builder constraints demo window slow to shrink2023-11-19T17:24:25ZIvan Molodetskikhyalterz@gmail.comBuilder constraints demo window slow to shrink## Steps to reproduce
1. Open Builder constraints `gtk4-demo`
2. Make it wider, it's smooth
3. Make it narrower, it's laggy
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or ...## Steps to reproduce
1. Open Builder constraints `gtk4-demo`
2. Make it wider, it's smooth
3. Make it narrower, it's laggy
<!--
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
*written in C* that exhibits the issue.
-->
## Expected outcome
Shrinking is also smooth.
## Version information
Fedora 33, Wayland, d278afc85b3355ab8e5e4fd14705e0685f05a9c6
## Additional information
[expanding.syscap](/uploads/f1f8aaf6492e275419ce0514a90dec9e/expanding.syscap)
[shrinking.syscap](/uploads/e488083025adf10303b86e1259a1c7dc/shrinking.syscap)
Expanding has this heavy path:
![Screenshot_from_2020-12-04_11-18-40](/uploads/36d9701b2c3c6745b53437932d3cf5ce/Screenshot_from_2020-12-04_11-18-40.png)
While shrinking also has this heavy call in addition to the above:
![Screenshot_from_2020-12-04_11-24-12](/uploads/6033707a2c50ba555906340e98fedcc1/Screenshot_from_2020-12-04_11-24-12.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/3430First item of popover menu tends to get briefly activated on open2021-06-04T14:27:18ZIvan Molodetskikhyalterz@gmail.comFirst item of popover menu tends to get briefly activated on open## Steps to reproduce
1. Open Application Class `gtk4-demo`
2. Open the menu and hover over it
## Expected outcome
First item isn't selected until I mouse over it.
## Version information
Fedora 33, f8ee4cfea5d5ed1b586caac7f30157d8...## Steps to reproduce
1. Open Application Class `gtk4-demo`
2. Open the menu and hover over it
## Expected outcome
First item isn't selected until I mouse over it.
## Version information
Fedora 33, f8ee4cfea5d5ed1b586caac7f30157d8977cf3a3
## Additional information
![2020-12-03_09-59-37](/uploads/ab1739c4013d819e2170110d010b05ea/2020-12-03_09-59-37.mp4)https://gitlab.gnome.org/GNOME/gtk/-/issues/3425GtkScale inside GtkPopover gets stuck when dragged to another surface2021-07-02T14:57:58ZRafał DzięgielGtkScale inside GtkPopover gets stuck when dragged to another surfaceThe `GtkScale` inside a `GtkPopover` does not remove its "clicked" state when mouse button is released on another surface and keeps looking as someone is still dragging it. Also sometimes the `GtkPopover` with that "stucked" scale does n...The `GtkScale` inside a `GtkPopover` does not remove its "clicked" state when mouse button is released on another surface and keeps looking as someone is still dragging it. Also sometimes the `GtkPopover` with that "stucked" scale does not want to close even when clicking outside of it.
This can be easily reproduced using the volume slider in `GtkVideo`. Just drag the slider and release the mouse button outside of popover (anywhere on the video). From this point onward, on every scale drag, the "pressed" state is not removed (even when released inside the popover) and sometimes the popover does not get closed on any click outside it.
Linux, GTK4 latest git at the time of writing (db456a70), gnome-shell, Wayland session.https://gitlab.gnome.org/GNOME/gtk/-/issues/3422macos: add support for apple pen device2024-01-13T21:27:02ZChristian Hergertmacos: add support for apple pen device*GTK4*
GTK 3 got support for apple pen devices since we moved to GTK 4 development. This needs to be forward ported.
/CC @icq*GTK4*
GTK 3 got support for apple pen devices since we moved to GTK 4 development. This needs to be forward ported.
/CC @icqhttps://gitlab.gnome.org/GNOME/gtk/-/issues/3421macos: support for keybinding translations2024-03-21T07:55:22ZChristian Hergertmacos: support for keybinding translations*GTK4*
Currently, the macOS backend does not have any translations for control/command keys and such. That means that we have very awkward keybindings compared to what we had on GTK 3.
It's not clear if we should just translate things ...*GTK4*
Currently, the macOS backend does not have any translations for control/command keys and such. That means that we have very awkward keybindings compared to what we had on GTK 3.
It's not clear if we should just translate things internally, or have some abstraction like we had before (yuck).Christian HergertChristian Hergerthttps://gitlab.gnome.org/GNOME/gtk/-/issues/3415Rename GtkScrolledWindow to GtkScrollArea2021-01-05T20:09:25ZMatthias ClasenRename GtkScrolledWindow to GtkScrollAreaThe window in the name is actively misleading at this point. We missed the boat for GTK4. Lets put this on the list for GTK5The window in the name is actively misleading at this point. We missed the boat for GTK4. Lets put this on the list for GTK5https://gitlab.gnome.org/GNOME/gtk/-/issues/3449Saving game should open home directory or at least a writable directory (by d...2020-12-06T15:04:18ZPiotr KubicaSaving game should open home directory or at least a writable directory (by default)Saving game does should open home directory or at least a writable directory.
Under Fedora 31 saving the game by default opens save dialog with a directory that cannot be written to.Saving game does should open home directory or at least a writable directory.
Under Fedora 31 saving the game by default opens save dialog with a directory that cannot be written to.https://gitlab.gnome.org/GNOME/gtk/-/issues/3409Custom CSS with dynamic reloading2020-12-06T00:04:52ZMikhail ZolotukhinCustom CSS with dynamic reloadingCurrently, GTK applications allow the user to provide custom CSS using `~/.config/gtk-<ver>/gtk.css` file. However, after changing the gtk.css GTK applications need to be restarted to apply the changes.
In KDE Plasma we use this feature...Currently, GTK applications allow the user to provide custom CSS using `~/.config/gtk-<ver>/gtk.css` file. However, after changing the gtk.css GTK applications need to be restarted to apply the changes.
In KDE Plasma we use this feature to match the appearance of our Breeze GTK theme according to user preferences (color scheme, windows decorations) and as of today we are using workaround for the theme update on the fly: GTK modules. Special module is loaded by default with each application, which watches the gtk.css changes and updates the CSS provider accordingly.
But as far as I know modules are no linger present in GTK 4 and because of that we are no longer able to dynamically update the appearance of GTK applications.
Could the GTK toolkit by itself dynamically update the CSS provider whenever gtk.css is changed? Or may be there could be a DBus signal we could pass to it, to reload the CSS from `~/.config/gtk-<ver>` directory?https://gitlab.gnome.org/GNOME/gtk/-/issues/3408GtkRevealer does not allow scolling of child widget GtkTextView2020-12-01T18:16:05ZBusayo FamutimiGtkRevealer does not allow scolling of child widget GtkTextView## Steps to reproduce
1. Create GtkWindow as top level widget
2. Insert a GtkBox in the window
3. Insert a GtkRevealer in the box
4. Insert a GtkScrolledWindow in the revealer
5. Insert a GtkViewPort in the scrolled window
6. Inse...## Steps to reproduce
1. Create GtkWindow as top level widget
2. Insert a GtkBox in the window
3. Insert a GtkRevealer in the box
4. Insert a GtkScrolledWindow in the revealer
5. Insert a GtkViewPort in the scrolled window
6. Insert a GtkTextView in the view port
A small program to reproduce the issue is attached (zip file) below
## Current behavior
The text in the GtkTextView does not scroll but if the GtkRevealer is removed, the text is scrollable.
## Expected outcome
The text within the GtkRevealer is expected to scroll.
## Version information
- GTK version 3.24.23
- Windows 10 via Msys2
## Additional information
A zip file is attached. Unzip the file, run `./compile.txt` and run `./test` to reproduce the issue.
[Gtk_Revealer_issue.zip](/uploads/b9050fc28557beb5b565863a99dadac9/Gtk_Revealer_issue.zip)https://gitlab.gnome.org/GNOME/gtk/-/issues/3398textview selection highlight may be shown when no selection2021-04-03T11:09:28ZMohammed Sadiqtextview selection highlight may be shown when no selectionSometime, with large text, the selection is still shown (and broken) when there should be no selection
How to reproduce:
1. Open `gtk4-demo --run=markup`
1. enable Source toggle
1. Select all text there and copy paste 15 times or so s...Sometime, with large text, the selection is still shown (and broken) when there should be no selection
How to reproduce:
1. Open `gtk4-demo --run=markup`
1. enable Source toggle
1. Select all text there and copy paste 15 times or so so that the buffer is large
1. Select pretty large portion of text using mouse click drag (up to the end of buffer)
1. Click somewhere in the selection
Result: The highlight of the line that was clicked last is gone, and the rest stays
![selection-textview](/uploads/66e409a784300925019c4017229cd87b/selection-textview.webm)https://gitlab.gnome.org/GNOME/gtk/-/issues/3396changing textview text properties breaks existing tags in widget-factory2021-04-03T11:09:28ZMohammed Sadiqchanging textview text properties breaks existing tags in widget-factoryChanging textview text properties breaks the existing text tags when the selection changes.
This was tested with `gtk4-widget-factory` textview in page 1. See attached video for details
![text-view-factory](/uploads/190175c3ab1e59ca3f2...Changing textview text properties breaks the existing text tags when the selection changes.
This was tested with `gtk4-widget-factory` textview in page 1. See attached video for details
![text-view-factory](/uploads/190175c3ab1e59ca3f250bbf99641f1a/text-view-factory.webm)https://gitlab.gnome.org/GNOME/gtk/-/issues/3391Change check- and radio-menuitems behavior2020-12-04T14:25:58ZArnaud B.arnaud.bonatti@gmail.comChange check- and radio-menuitems behavior<small>(Split from #3383.)</small>
In Gtk3, popovers created *via* `gtk_menu_button_set_menu_model()` close when a “simple-entry” is clicked, but stay opened when it’s a “check-entry” or a “radio-entry”.
This behavior looks good (examp...<small>(Split from #3383.)</small>
In Gtk3, popovers created *via* `gtk_menu_button_set_menu_model()` close when a “simple-entry” is clicked, but stay opened when it’s a “check-entry” or a “radio-entry”.
This behavior looks good (examples taken from various games I maintain):
* a “Sound” check-entry will not give directly feedback, so having the popover staying opened allows to see whether you correctly enabled/disabled the sound, and didn’t clicked out of the popover for example;
* you can replace a Preferences dialog easily by a menu/submenu, because multiple booleans options could be toggled at the same time;
* in an “Appearance” menu, multiple radio-entries allows to test every game theme, for finding the one you need, before closing the popover once you choosed;
* a simple-entry will usually do something visible anyway, like open a dialog (think of “Help” or “About”), so closing is okay
![Capture_d_écran_vidéo_de_23-11-2020_14_34_53](/uploads/cdcc3b07d342b0dfff84d1c1ab4b4efb/Capture_d_écran_vidéo_de_23-11-2020_14_34_53.webm)
This behavior is not the one currently in Gtk4, because the created popover is now a “standard menu,” that (IIUC) comes from the time when we used menubars: for now, every menuitem clicked closes the menu. It would be quite better for every “standard menu” to use the Gtk3 behavior of the popover from the `GtkMenuButton`, because that’s working great with current UI paradigms.https://gitlab.gnome.org/GNOME/gtk/-/issues/3388Scrolling hangs under Nvidia/X11 if Window tiled to the side2021-04-03T11:09:28ZaeldemeryScrolling hangs under Nvidia/X11 if Window tiled to the sideSorry couldn't take a gif.
As the title said there is some issue with scrolling under proprietary NVIDIA driver and X11 specially if the window is attached to the edge of screen/tiled.
Manjaro-Linux
```
lspci | grep VGA
01:00.0 VGA co...Sorry couldn't take a gif.
As the title said there is some issue with scrolling under proprietary NVIDIA driver and X11 specially if the window is attached to the edge of screen/tiled.
Manjaro-Linux
```
lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GP104BM [GeForce GTX 1070 Mobile] (rev a1)
```
```
lshw -C video
*-display
description: VGA compatible controller
product: GP104BM [GeForce GTX 1070 Mobile]
vendor: NVIDIA Corporation
physical id: 0
bus info: pci@0000:01:00.0
version: a1
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
configuration: driver=nvidia latency=0
resources: irq:138 memory:bb000000-bbffffff memory:90000000-9fffffff memory:a0000000-a1ffffff ioport:4000(size=128) memory:c0000-dffff
```
installed package versions
```
xorg-server 1.20.9.r21.g5c400cae1-1
nvidia 455.45.01
mutter 3.38.1-1
```
![VID_20201122_204704](/uploads/f94e2efdd9e31e6762ea07a72fc8569e/VID_20201122_204704.mp4)https://gitlab.gnome.org/GNOME/gtk/-/issues/3378Part hidden text in "Modified" column when "save as" file chooser is opened2020-11-19T16:02:24ZSTOMPY05Part hidden text in "Modified" column when "save as" file chooser is opened## Steps to reproduce
Open save / save-as file dialog box in any application that opts to save in an empty directory or a directory that has no current file types as the one currently being saved.
## Current behavior
Modified column tex...## Steps to reproduce
Open save / save-as file dialog box in any application that opts to save in an empty directory or a directory that has no current file types as the one currently being saved.
## Current behavior
Modified column text is part hidden until window, columns, or sidebar are resized.
## Expected outcome
"Modified" column text should appear in full regardless.
## Version information
GTK Version 3.24.20-0ubuntu1
Ubuntu 20.04
## Additional information
![Screenshot](/uploads/c989c4115ced826737153bd3499dfe58/Screenshot.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/3375GtkListBox .separators and the last row2024-02-29T17:57:06ZSophie HeroldGtkListBox .separators and the last rowThe gtk4-demo ListBox/Controls uses a `.separators` ListBox with a GtkFrame around it. The last row gets a `border-bottom` from `.separators` and the GtkFrame border below. This looks not intentional.
I think that not only the demo shou...The gtk4-demo ListBox/Controls uses a `.separators` ListBox with a GtkFrame around it. The last row gets a `border-bottom` from `.separators` and the GtkFrame border below. This looks not intentional.
I think that not only the demo should be fixed but there should be a nice solution for this design pattern, since it is quite common. Favorably without GtkFrame to support placeholder content without a frame.
_LibHandy fixes this for it's `.content` class by using `:last-child`. However, this approach breaks if the ListBox has a placeholder. I would have fixed it using `:last-of-type` but that's not available in gtk. (Uses of pseudo classes were removed anyways because they are expensive bfe5b0d1b7a13749642a94a8a75fd82b6401a9ae)_https://gitlab.gnome.org/GNOME/gtk/-/issues/3367Clipboard hang destination app2020-12-17T15:50:18ZNicolas GoyClipboard hang destination appThe firefox bug with more details is: https://bugzilla.mozilla.org/show_bug.cgi?id=1631061
I open an issue here as I am not sure if this is now a GTK bug, and many GTK devs know more and can help me debug this.The firefox bug with more details is: https://bugzilla.mozilla.org/show_bug.cgi?id=1631061
I open an issue here as I am not sure if this is now a GTK bug, and many GTK devs know more and can help me debug this.https://gitlab.gnome.org/GNOME/gtk/-/issues/3365Make gtk_tree_model_foreach return last walked path2020-11-15T22:59:40ZcryptogopherMake gtk_tree_model_foreach return last walked pathLink to code: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtktreemodel.c#L2015
Right now `gtk_tree_model_foreach()` return type is void.
`gtk_tree_model_foreach()` calls the user defined `GtkTreeModelForeachFunc` callback/func...Link to code: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtktreemodel.c#L2015
Right now `gtk_tree_model_foreach()` return type is void.
`gtk_tree_model_foreach()` calls the user defined `GtkTreeModelForeachFunc` callback/func:
```c
* Calls func on each node in model in a depth-first fashion.
*
* If @func returns %TRUE, then the tree ceases to be walked,
* and gtk_tree_model_foreach() returns.
```
It would be useful if `gtk_tree_model_foreach()` returned the tree path, for which `@func` returned TRUE.
Such functionality would allow using `gtk_tree_model_foreach()` to search through tree items until matching element is found.https://gitlab.gnome.org/GNOME/gtk/-/issues/3360Add PackType to flowbox2020-11-15T16:11:28ZaggelalexAdd PackType to flowboxCurrently there's no way to position the children in a flowbox at the end or at the start of the container.Currently there's no way to position the children in a flowbox at the end or at the start of the container.https://gitlab.gnome.org/GNOME/gtk/-/issues/3357Editing and Drag-and-Drop demo click criticals and warnings2021-04-03T11:09:28ZIvan Molodetskikhyalterz@gmail.comEditing and Drag-and-Drop demo click criticals and warnings## Steps to reproduce
1. Open Editing and Drag-and-Drop `gtk4-demo`.
2. Click on one of the things.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the ...## Steps to reproduce
1. Open Editing and Drag-and-Drop `gtk4-demo`.
2. Click on one of the things.
<!--
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
*written in C* that exhibits the issue.
-->
## Current behavior
<!--
Please describe the current behaviour
-->
```
(gtk4-demo:301327): Gtk-WARNING **: 22:53:41.407: Allocating size to GtkEntry 0x2c72d00 without calling gtk_widget_measure(). How does the code know the size to allocate?
(gtk4-demo:301327): Gtk-CRITICAL **: 22:53:41.407: Allocation width too small. Tried to allocate 48x24, but GtkEntry 0x2c72d00 needs at least 51x24.
(gtk4-demo:301327): Gtk-CRITICAL **: 22:53:41.407: Allocation width too small. Tried to allocate 42x18, but GtkText 0x2774800 needs at least 45x18.
```
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Fedora 33, Wayland, 25e6988d95f951ca2464bdcda8eeac1bbb4657fd default options.https://gitlab.gnome.org/GNOME/gtk/-/issues/3351GtkTreeView: item selection with Shift key - Different behavior depending on ...2021-04-28T16:09:44ZKevin Ilphrin PelletGtkTreeView: item selection with Shift key - Different behavior depending on the "direction"GIMP version: 2.99.2
Operating System: Pop_OS 20.10 64 bits
Package: Flatpak beta
# Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
When I ...GIMP version: 2.99.2
Operating System: Pop_OS 20.10 64 bits
Package: Flatpak beta
# Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
When I have more than 2 layers (I have 5 layers in my example GIF), and layers 2 and 3 are selected there is two behavior:
- If layer 3 is the last I selected, and i select the layer 4 by using the shift key, layers 3 and 4 are selected
- If layer 2 is the last I selected, and I select the layer 1 (still using the Shift key method), layers 1, 2 and 3 are selected
![GimpMultiLayersSelectionBug](/uploads/41bfc19a758a695ee793ee5ebff3ad2f/GimpMultiLayersSelectionBug.gif)
# Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Create more than two layers
2. Select the first one
3. Select the second by keeping Shift key pressed
4. Select the third layer (still keeping the Shift key pressed)
The first layer is then deselected
…
Expected result: Should have the same behavior when selecting from bottom to top or from top to bottom
Actual result: From bottom to top, it selects the very first layer selected to the very last. From top to bottom, it selects the previous clicked layer to the very last layer
Note: French guy here, apologies if my English is poor :') Thank you all for your awesome work on GIMP, I'll keep trying the latest 2.99 and report new bugs :3