gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2019-03-27T10:52:46Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/1769GContentType usage on win322019-03-27T10:52:46ZMarc-André LureauGContentType usage on win32Hi,
Since commit e387f807e4a6da663bca3f8d0b75f1cdbd66465d ("Improve GContentType usage"), `g_content_type_from_mime_type()` is called on the mime types before calling `g_content_type_is_a()`. While it is more correct, it also breaks exi...Hi,
Since commit e387f807e4a6da663bca3f8d0b75f1cdbd66465d ("Improve GContentType usage"), `g_content_type_from_mime_type()` is called on the mime types before calling `g_content_type_is_a()`. While it is more correct, it also breaks existing applications.
The way `g_content_type_from_mime_type()` works on win32, is via a registry lookup, which returns the associated extension if the mime type is known or NULL.
In the most simplest version `g_content_type_is_a()` is simply a string comparison.
Before that commit, an unregistered MIME type would be successfully compared.
After the commit, the comparison can't happen with NULL return values. Furthermore, there are some pre-condition criticals from gtk/gtkrecentfilter.c, since NULL isn't checked before calling `g_content_type_is_a()`.
Either we consider this a regression, and use a simple fallback to compare mime_type directly when `g_content_type_from_mime_type()` fails, or we should close as wontfix and blame the existing applications that rely on unregistered mime types.
Fwiw, even testrecentchooser.exe fails on my Windows machine, since 'application/pdf' isn't a registered MIME type...https://gitlab.gnome.org/GNOME/gtk/-/issues/1758gedit search box is broken on Windows2019-04-01T01:39:48ZFabian Greffrathgedit search box is broken on WindowsHi there,
I am using gedit on Windows using the binaries provided by the MSYS2 project [1].
Since the upgrade to gtk3 3.24.2-1, searching is broken in gedit.
Step to reproduce:
Try to open a file, hit CTRL+F and type a string: it won...Hi there,
I am using gedit on Windows using the binaries provided by the MSYS2 project [1].
Since the upgrade to gtk3 3.24.2-1, searching is broken in gedit.
Step to reproduce:
Try to open a file, hit CTRL+F and type a string: it won't appear in the search box. Now, hit ESC to close the search box, hit CTRL+F again and start to type. Now, it will work as expected.
I can confirm that the feature broke between 3.24.1-1 (which works) and 3.24.2-1 (which does not)!
Unfortunately neither the gtk3 3.24.3 nor the 3.24.4 upgrade solved this issue.
[1] https://github.com/msys2/MINGW-packages/issues/4838
Cheers,
- Fabianhttps://gitlab.gnome.org/GNOME/gtk/-/issues/2129Ugly fonts when using fractional scaling on Wayland2021-04-03T11:23:30ZOlivier FourdanUgly fonts when using fractional scaling on WaylandWhile investigating issue https://gitlab.gnome.org/GNOME/gtk/issues/2128 I noticed the fonts where ugly, not rendered correctly, as if scaled incorrectly:
![Screenshot_from_2019-09-03_12-50-13](/uploads/d574fc95455acd34d5a718ec3c06d546/...While investigating issue https://gitlab.gnome.org/GNOME/gtk/issues/2128 I noticed the fonts where ugly, not rendered correctly, as if scaled incorrectly:
![Screenshot_from_2019-09-03_12-50-13](/uploads/d574fc95455acd34d5a718ec3c06d546/Screenshot_from_2019-09-03_12-50-13.png)
It turns out it is not related to the xdg-output shenanigans, but instead another commit:
https://gitlab.gnome.org/GNOME/gtk/commit/6d545b6d
```
commit 6d545b6d03caba8e7718a73c6e0abe35a4133fe0
Author: Lionel Landwerlin <llandwerlin@gmail.com>
Date: Sat Aug 3 22:31:53 2019 +0300
gdk/wayland: go through monitor to compute scale factor
The current code only goes through the output associated to the
window's wayland surface enter/leave events. That means that to update
the scale factor the window only looks at the outputs on which it
received enter/leave events. That doesn't include a new monitor
connected to the system on which the window might be display next.
The spirit of the existing logic seems to be to go through all the
scale factor available on the current monitors of the system and pick
the highest. So fix the current behavior by looking at the monitor on
the display.
Fixes #1144.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
```
Reverting that commit fixes the issue for me.
Steps to reproduce on a dual screen setup:
- Save and compile the attached simple reproducer: [screensize.c](/uploads/381f97ddf0abd5a016f328edd94f32cb/screensize.c)
- Enable fractional scaling in mutter (Add 'scale-monitor-framebuffer' to org.gnome.mutter 'experimental-features')
- Set a fractional scale on only one output
- Run the reproducer
Expected result:
When moving from one monitor to the other (of different scale), the scale of the window (as indicated in the title bar of the reproducer window) should change (from scale 1 to scale 2 and vice versa, adapting to the monitor scale).
Actual result:
The scale factor of the window does not change.
Additional data
As far as I can see, this does not affect gtk4.https://gitlab.gnome.org/GNOME/gtk/-/issues/2034Icon of Totem running on KDE Plasma Wayland session is incorrect in alt+tab menu2022-04-04T14:47:30ZStrangiatoIcon of Totem running on KDE Plasma Wayland session is incorrect in alt+tab menutotem 3.32.1-1 on Arch Linux.
This issue was already reported to KDE devs.
https://bugs.kde.org/show_bug.cgi?id=409967
app_id and .desktop file name must match.totem 3.32.1-1 on Arch Linux.
This issue was already reported to KDE devs.
https://bugs.kde.org/show_bug.cgi?id=409967
app_id and .desktop file name must match.https://gitlab.gnome.org/GNOME/gtk/-/issues/4618Background blend mode clip interaction not working as intended on mips*el2022-08-15T21:11:30ZSimon McVittieBackground blend mode clip interaction not working as intended on mips*elWith GTK 4.6.0 on Debian mipsel (little-endian MIPS32R2) and mips64el (little-endian MIPS64R2), in addition to #4228, I'm seeing a reftest failure for `background-blend-mode-clip-interaction`.
Reference:
![background-blend-mode-clip-in...With GTK 4.6.0 on Debian mipsel (little-endian MIPS32R2) and mips64el (little-endian MIPS64R2), in addition to #4228, I'm seeing a reftest failure for `background-blend-mode-clip-interaction`.
Reference:
![background-blend-mode-clip-interaction.ref](/uploads/b4441932c7a2ebabecefe22c955130b0/background-blend-mode-clip-interaction.ref.png)
Actual:
![background-blend-mode-clip-interaction.out](/uploads/e6773537a0078da1fd3d7180fb203150/background-blend-mode-clip-interaction.out.png)
Highlighted diff:
![background-blend-mode-clip-interaction.diff](/uploads/82a1a8e2ea3a7979070611e60de0b0ed/background-blend-mode-clip-interaction.diff.png)
As with #4228, I'll try to get the Debian mips porting team involved.https://gitlab.gnome.org/GNOME/gtk/-/issues/5467MSVC: Deadlock issue when calling gdk_win32_clipdrop_init2022-12-25T17:49:53ZWilliam Roywroy@proton.meMSVC: Deadlock issue when calling gdk_win32_clipdrop_initThere is a deadlock with Microsoft Visual C++ caused by(around) ~gdkclipdrop-win32.c:1613:
```cpp
win32_clipdrop->n_known_pixbuf_formats = 0;
for (rover = pixbuf_formats; rover != NULL; rover = rover->next)
{
char **mime_ty...There is a deadlock with Microsoft Visual C++ caused by(around) ~gdkclipdrop-win32.c:1613:
```cpp
win32_clipdrop->n_known_pixbuf_formats = 0;
for (rover = pixbuf_formats; rover != NULL; rover = rover->next)
{
char **mime_types =
gdk_pixbuf_format_get_mime_types ((GdkPixbufFormat *) rover->data);
char **mime_type;
for (mime_type = mime_types; *mime_type != NULL; mime_type++)
win32_clipdrop->n_known_pixbuf_formats++;
}
```
```
[External Code]
> [Inline Frame] glib-2.0-0.dll!g_async_queue_pop_intern_unlocked(_GAsyncQueue *) Line 425 C
glib-2.0-0.dll!g_async_queue_pop(_GAsyncQueue * queue) Line 459 C
gtk-4-1.dll!gdk_win32_clipdrop_init(_GdkWin32Clipdrop * win32_clipdrop) Line 1842 C
gobject-2.0-0.dll!g_type_create_instance(unsigned __int64 type) Line 2009 C
gobject-2.0-0.dll!g_object_new_internal(_GObjectClass * class, _GObjectConstructParam * params, unsigned int n_params) Line 2246 C
gobject-2.0-0.dll!g_object_new_with_properties(unsigned __int64 object_type, unsigned int n_properties, const char * * names, const _GValue * values) Line 2411 C
gobject-2.0-0.dll!g_object_new(unsigned __int64 object_type, const char * first_property_name, ...) Line 2062 C
gtk-4-1.dll!_gdk_win32_clipdrop_init() Line 1526 C
gtk-4-1.dll!_gdk_win32_surfaceing_init() Line 79 C
gobject-2.0-0.dll!type_class_init_Wm(_TypeNode * node, _GTypeClass * pclass) Line 2367 C
gobject-2.0-0.dll!g_type_class_ref(unsigned __int64 type) Line 3082 C
gobject-2.0-0.dll!g_object_new_with_properties(unsigned __int64 object_type, unsigned int n_properties, const char * * names, const _GValue * values) Line 2388 C
gobject-2.0-0.dll!g_object_new(unsigned __int64 object_type, const char * first_property_name, ...) Line 2062 C
gtk-4-1.dll!_gdk_win32_display_open(const char * display_name) Line 523 C
gtk-4-1.dll!gdk_display_manager_open_display(_GdkDisplayManager * manager, const char * name) Line 424 C
gtk-4-1.dll!gtk_init_check() Line 623 C
gtk-4-1.dll!gtk_init() Line 661 C
gtksourceview-5-0.dll!gtk_source_init() Line 191 C
[Inline Frame] gtksourceview-5-0.dll!_gtk_source_init_ctor() Line 256 C
gtksourceview-5-0.dll!_gtk_source_init_ctor_wrapper() Line 251 C
[External Code]
```
_This was initially stumbled upon with gtksourceview https://gitlab.gnome.org/GNOME/gtksourceview/-/commit/441ccc244c068124ea687f379fe6935e46fcdd2b revision_https://gitlab.gnome.org/GNOME/gtk/-/issues/2530Inserting an hyphen at line breaks looks wrong in applications like gedit2023-01-10T23:14:08ZSimon SapinInserting an hyphen at line breaks looks wrong in applications like geditI don’t know if this should be filed on gtksourceview instead.
In its default configuration, Gedit wraps lines that are longer than the window is wide. In 3.34.1 or some recent version before that (sorry I don’t know which), it started ...I don’t know if this should be filed on gtksourceview instead.
In its default configuration, Gedit wraps lines that are longer than the window is wide. In 3.34.1 or some recent version before that (sorry I don’t know which), it started inserting an hyphen character to indicate breaks at some non-whitespace locations. (I don’t know if such breaks were done at all before.)
In the screenshot below, the two lines of text differ only by whitespace. The `-` is not part of the file, although there is no visible indication of that:
<img src=https://gitlab.gnome.org/GNOME/gedit/uploads/8c3dd50c84ee76e6d89d05f9ceb5b1e6/Screenshot_from_2019-11-25_10-12-05.png width=600px>
While proper hyphenation can be useful when rendering prose, I feel this Gedit behavior is wrong and should be disabled:
* Gedit is often use to edit source code rather than only prose. Punctuation characters are significant in most programming languages, so auto-hyphenation can look like a syntax error or a program that behaves differently. So auto-hyphenation should at least not be the default.
* Correct hyphenation breaks in the middle of a word and the hyphen visually joins *letters* that would otherwise be adjacent. Even in prose, inserting `-` after another punctuation character like `/` looks wrong.
* Gedit is a plain text editor, not just for visualization and not usually not WYSIWYG. It is its role to visually show what characters are part or not part of the file. Even if hyphenation is opted-in and made more correct, it should be visually distinct from an actual `-` character in the file.
Consider the “Show spaces” plugins which (among other things) renders hard tabs as an arrow. It uses a color different from that of file contents, and with low contrast from the background, in order to visually indicate that this arrow is not an actual U+27F6 ⟶ LONG RIGHTWARDS ARROW character in the file.https://gitlab.gnome.org/GNOME/gtk/-/issues/5588Mouse cursor is blurry inside GTK4 apps on HiDPI display2023-02-14T03:37:42ZhexchainMouse cursor is blurry inside GTK4 apps on HiDPI display## Steps to reproduce
(Tested under Plasma and Sway, Wayland, 3840x2160, 200% HiDPI)
1. Change the mouse cursor theme to something other than Adwaita, e.g. Breeze or [McMojave-cursors](https://github.com/vinceliuice/McMojave-cursors)
...## Steps to reproduce
(Tested under Plasma and Sway, Wayland, 3840x2160, 200% HiDPI)
1. Change the mouse cursor theme to something other than Adwaita, e.g. Breeze or [McMojave-cursors](https://github.com/vinceliuice/McMojave-cursors)
2. Open a GTK4 app (gtk4-demo would work) and move the mouse cursor onto it
## Current behavior
gtk4-demo (4.7.1+) with McMojave-cursors (size is 24)
![image](/uploads/73fa830b9219f8242faa34476ada9d35/image.png)
Notice that the mouse cursor is pixelated.
## Expected outcome
gtk3-demo (3.24.36)
![image](/uploads/58b12c7b208832ddabeaa4dcd497e562/image.png)
gtk4-demo (4.7.0)
![image](/uploads/5aaa0a80104859353b7128a4ae8c097f/image.png)
## Version information
gtk4 4.8.3, but it started to happen in 4.7.1.
## Additional information
The issue seems to have been introduced in !4761, according to git bisect.https://gitlab.gnome.org/GNOME/gtk/-/issues/5670Rubberband selection starting instead of drag and drop if mouse starts moving...2023-03-16T09:20:42ZOndrej HolyRubberband selection starting instead of drag and drop if mouse starts moving too soon<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see http...<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in a Terminal:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3) The Nightly version can now be launched from Activities, or with this command: flatpak run org.gnome.NautilusDevel
-->
# Affected version
- Nightly flatpak: Yes
- Other: nautilus-44~alpha-2.fc38.x86_64, gtk4-4.9.3-1.fc38.x86_64
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
Easiest way is:
1. Move mouse slowly and continuously
2. Hold left mouse button to start a DnD
# Current behavior
<!-- Describe the current behavior. -->
Rubberband starts instead of DnD.
# Expected behavior
<!-- Describe the expected behavior. -->
DnD starts as appropriate.
# Additional information
<!--
Provide more information that could be relevant.
If the issue is a crash, provide a stack trace following the steps in:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
-->
If the mouse is stationary when pressing left even for a split-second, drag and drop will start successfully (rubberband will show up for a moment but then DnD will replace it). However, this is just barely long enough to make all of my regular usage DnDs on a mouse fail to start.
Also works on a touchpad, if using a physical left mouse button. Double tap then drag seems to leave the pointer stationary long enough that the bug does not trigger.
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/gtk/-/issues/6260memorytexture test on big-endian regressed in "gsk: Use has_bgra in more places"2024-03-01T12:00:37ZSimon McVittiememorytexture test on big-endian regressed in "gsk: Use has_bgra in more places"Since 4.12.4, the memorytexture test fails:
> ```
> test: gtk:gdk / memorytexture
> start time: 16:40:53
> duration: 0.64s
> result: killed by signal 6 SIGABRT
> ...
> 1..2072
> # Start of memorytexture tests
> # Sta...Since 4.12.4, the memorytexture test fails:
> ```
> test: gtk:gdk / memorytexture
> start time: 16:40:53
> duration: 0.64s
> result: killed by signal 6 SIGABRT
> ...
> 1..2072
> # Start of memorytexture tests
> # Start of download_1x1 tests
> # Start of b8g8r8a8-premultiplied tests
> ok 1 /memorytexture/download_1x1/b8g8r8a8-premultiplied/local
> not ok /memorytexture/download_1x1/b8g8r8a8-premultiplied/gl - ERROR:../../../testsuite/gdk/memorytexture.c:819:compare_textures: 'gdk_memory_format_pixel_equal (format, accurate_compare, data1 + bpp * x, data2 + bpp * x)' should be TRUE
> ```
Big-endian ppc64 has a similar failure mode, suggesting that this is an endianness problem.
Bisecting indicates 41dbb7a7 as the first bad commit. The following commit 5ff9316e was meant to fix big-endian, but it appears that it didn't.
It looks as though this can be solved by always taking the "BGRA unsupported" code path on big-endian.https://gitlab.gnome.org/GNOME/gtk/-/issues/6201GtkEntry: bouncing progress bar not displayed [regression]2024-03-12T16:03:51ZgwillemsGtkEntry: bouncing progress bar not displayed [regression]
## Steps to reproduce
1. Start `gtk4-widget-factory`
2. Click on the reload icon of the 3rd entry
![test](/uploads/1f9535552cc89492eb6d004f4b25b08c/test.png)
## Current behavior
Nothing happens
## Expected outcome
Bouncing progr...
## Steps to reproduce
1. Start `gtk4-widget-factory`
2. Click on the reload icon of the 3rd entry
![test](/uploads/1f9535552cc89492eb6d004f4b25b08c/test.png)
## Current behavior
Nothing happens
## Expected outcome
Bouncing progress bar
## Version information
Gtk main branch (commit 5850055b and newer)
Official releases *not* affected (tested 4.12.3)
## Additional information
Regression introduced by !6445
Observed with the Gtk4 Default and Default-dark themes (it's css-related, so maybe could be fixed in themes only)4.14.2