GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-25T20:20:56Zhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1175Calendar's .ics individual event file importing dialog does not preview times...2024-03-25T20:20:56ZJeff FortinCalendar's .ics individual event file importing dialog does not preview times in user's local timezone, and does not respect 24-hours vs 12-hours AM PM formatTo reproduce:
1. Download [this sample .ics file](https://gitlab.gnome.org/GNOME/gnome-calendar/uploads/6c90ca389766b6245906c59434e19512/appointment-53357.ics) (from issue #790), which has UTC times* using the "Z" format, such as:
```...To reproduce:
1. Download [this sample .ics file](https://gitlab.gnome.org/GNOME/gnome-calendar/uploads/6c90ca389766b6245906c59434e19512/appointment-53357.ics) (from issue #790), which has UTC times* using the "Z" format, such as:
```
DTSTAMP:20220202T224658Z
DTSTART:20220208T123000Z
DTEND:20220208T133000Z
```
2. In Nautilus, right-click the file, "Open With…", and choose GNOME Calendar nighly (instead of Evolution, if installed)
3. Observe the resulting "Import 1 event" dialog's previews, vs what actually gets imported/saved after the process is done
*Tip: before importing, you can edit the .ics file with a text editor, to replace all the `2022` by the current year to facilitate testing.
## Actual results
With the nightly / 46 version, the resulting dialog appears, with the UTC times rendered as if they were the local system's time (i.e. they always show up as being 12:30 to 13:30, no matter what your local timezone is):
| ❌ How GNOME Calendar's import dialog previews it | ✅ How Evolution's import dialog previews it |
| ------ | ------ |
| ![image](/uploads/4322f60a26da8af98aba0f47766c02de/image.png) | ![image](/uploads/e96da8882efb414c8f71fe3e0021d11d/image.png) |
Note that this is just _displaying_ the wrong times in _that particular preview dialog;_ the event that actually gets imported/saved by the backend into the resulting views (month view, week view, etc.) is correctly stored as UTC and displayed at the user's local timezone… for example:
![image](/uploads/a718070061b27216cb42a4f09259872a/image.png)
## Expected results
The bugfix needed here is two things:
* Use the user's local system timezone to display/preview the times in Calendar's individual file import wizard dialog
* Use the system Settings (from GNOME Settings / gsettings) to display the time in 24-hours vs 12-hours (AM/PM) format, like the rest of GNOME Calendar's UI components.
---
Potentially related gotcha for the future: inversely, #171 would require events to be rendered in the local time instead of being considered UTC to be converted!GNOME 47https://gitlab.gnome.org/GNOME/mutter/-/issues/3229xdg-toplevel is marked as suspended while it's visible and renders2024-03-25T19:37:50ZKirill Chibisovxdg-toplevel is marked as suspended while it's visible and renders### Affected version
45.2, probably broken right after when suspended was added.
This is all on fedora 39 without any extensions to gnome shell.
### Bug summary
The window has `SUSPENDED` state for the first configure preventing it f...### Affected version
45.2, probably broken right after when suspended was added.
This is all on fedora 39 without any extensions to gnome shell.
### Bug summary
The window has `SUSPENDED` state for the first configure preventing it from being shown
when the client uses that information to decide when to render or not.
### Steps to reproduce
You'd need alacritty 0.13.0 and run it with
`alacritty -o "window.startup_mode='Maximized'"` or `Fullscreen` instead of maximized.
This is **not** happening when the window is run without those mods.
### What happened
Window is invisible because it thinks that it's suspended, thus it doesn't try to render.
### What did you expect to happen
Never set `SUSPENDED` for the first configure.
### Relevant logs, screenshots, screencasts etc.
`WAYLAND_DEBUG=1` log interleaved with some extra alacritty logging and a configure dump.
[log.txt](/uploads/8f300531cb3eacb2b5a8c60f2ccd1729/log.txt)https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6553Standard Alt+Tab / Super+Tab ("Switch applications") window switcher shortcut...2024-03-25T17:27:43ZJeff FortinStandard Alt+Tab / Super+Tab ("Switch applications") window switcher shortcut behavior breaks (becomes "sticky" or "off by one MRU") after some time running### Affected version
* OS and version: Fedora 38 (also F37)
* Affected GNOME Shell version: 44.x (also 43.x), and probably prior versions
* XOrg vs Wayland: I've tested this on X11 and I keep encountering it there, I _think_ it might ha...### Affected version
* OS and version: Fedora 38 (also F37)
* Affected GNOME Shell version: 44.x (also 43.x), and probably prior versions
* XOrg vs Wayland: I've tested this on X11 and I keep encountering it there, I _think_ it might happen with Wayland but I'm not sure.
* Does this issue happen without extensions: yes
### Bug summary
Alt-Tab inexplicably breaks after gnome-shell has been running for a while while using it. I've been unable to find the exact cause/trigger so far, other than active use / time passing.
This is a bit similar to #5348 and #5373, but:
* It's not just a matter of how fast you do it (5348), which used to be the old incarnation of this problem prior to GNOME 41/42... it seems the behavior has now regressed since version 42 (and 43/44) and applies no matter how fast or slow you are
* It's not affecting `Alt+Esc`, it's affecting the standard default behavior of `Super+Tab` / `Alt+Tab` (switch between applications) and `Alt + the_key_above_tab` (switch between windows of the current application)
I'm pretty sure this is a regression that occurred in 42-43, and it went mostly unnoticed because it manifests itself only after the shell has been running for a while... but it's been crippling my day-to-day user experience of GNOME Shell since then.
### Steps to reproduce
1. Use GNOME Shell for a while (it could be one hour, two hours, 20 hours, before the issue manifests itself; having apps like Gedit, Firefox etc. open seems to help trigger the issue)
2. Try to quickly `Alt+Tab` to switch between your two most-recently-used (MRU) applications
### What happened
When the bug is effective, `Alt+Tab` does not easily switch between applications/windows, it "sticks" to the current application. I've noticed this especially with Firefox, Gedit and applications that have multiple windows... but that might just be a coincidence.
More technically, the way the issue happens is that it always preselects the "wrong" choice when I press `Alt+Tab` and release `Tab` (while keeping `Alt` pressed). I can't find a way to describe this other than it "sticks" like glue to the 2nd item in the app switcher's list once you're focused on it, and doesn't swap it with the 1st item, so you can't `Alt+Tab` repeatedly to "alternate switch" between two apps you're currently using, and that's a huge regression to me.
### What did you expect to happen
Always correctly pre-select the "other most recently used application" in the window switcher the first time I hit Alt+Tab (or instantly switch between the two if I release the Alt+Tab shortcut immediately)
### Additional info
* This bug does not happen at the beginning with a "fresh" GNOME Shell, as you would see if you reload GNOME Shell (`Alt+F2, r, Enter` when running in a Xorg session; if you're running Wayland, you'll probably have to logout+relogin instead)... then after some hours of use, the issue comes back
* The issue is not related to having multiple screens / monitors connected, as it also happens on my laptop when it's running on its own, disconnected, and having restarted GNOME Shell (with `Alt+F2, r`).
* The issue is not related to animations/performance, as it happens even with animations turned off in accessibility settings, and it is triggered "at some point in time" on the same machine (so the performance should not be a variable there)
* I think the issue is not related to virtual workspaces either
* The issue is not related to minimizing/unminimizing windows, or tiling/untiling (with the super+up/down/left/right keys)
* Not related to extensions. Happens with a vanilla GNOME Shell, with or without dash/docks/etc., and even with any alternative alt-tabbing extensions (I've been desperately trying to find a workaround for the issue)
I am quite lost at this point on what to do with this, as it seems there have been so many tickets and branches attempting to fix this, but the problem persists, and I still don't know exactly what triggers it. I've heard other anecdotal stories of people encountering this bug, and I even saw someone describing the same symptoms in [a reddit thread](https://www.reddit.com/r/gnome/comments/123421d/why_do_my_alttab_doesnt_switch_to_the_next/) today, where there is a video demonstrating the issue, so certainly I am not the only one suffering from this; it's just hard for me to pinpoint what is causing the issue to manifest "after a while".
Here is the output from `journalctl /usr/bin/gnome-shell` (as you can see I reloaded the shell a couple of times to work around the problem): [gnome_shell_journalctl_output.txt](/uploads/496e2727c8b679bd1771b931459fab7a/gnome_shell_journalctl_output.txt)https://gitlab.gnome.org/GNOME/mutter/-/issues/11933.34.4+: getting a white screen on 2nd monitor, optimus setup, wayland2024-03-25T15:04:34ZPierre C.3.34.4+: getting a white screen on 2nd monitor, optimus setup, wayland<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Mutter version where the bug is present: 3.34.4+ (betwee...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Mutter version where the bug is present: 3.34.4+ (between 3.34.3 and 2709a4ffb according to the Debian packaging - https://gitlab.gnome.org/GNOME/mutter/-/compare/3.34.3...2709a4ffb).
OS: Debian.
I'm using Wayland, nouveau only, no nvidia driver.
<!--
Provide at least the following information:
* Your OS and version
* Affected Mutter version
* Does this issue appear in XOrg and/or Wayland
-->
### Bug summary
When upgrading to 3.34.4 (here 2709a4ffb) and above (including 3.36), I have my second screen fully white, but I'm able to see the mouse pointer on it.
The first screen (integrated one) show glitches and freezes during a few tens of secs. probably while trying to sync the other one before aborting.
I started a thread on Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956121), but now I'm quite convinced that this is coming from the upstream package.
I'm not experienced in debugging such graphic issues, so sorry in advance if I'm missing obvious details.
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
* Upgrade to 3.34.4+
* gdm3 stop/start.
### What happened
<!--
What did Mutter do that was unexpected?
-->
2nd display unusable: fully white, 1rst of get glitches every 5s or so.
### What did you expect to happen
<!--
What did you expect Mutter to do?
-->
Ability to use my 2 monitors.
### Relevant logs, screenshots, screencasts etc.
HW config:
```
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro
K2000M] (rev a1)
```
Seeing such things when this is happening:
```
avril 10 11:46:25 dell-m4700 kernel: dmar_fault: 191660 callbacks suppressed
avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3
avril 10 11:46:25 dell-m4700 kernel: DMAR: [DMA Read] Request device
[01:00.0] PASID ffffffff fault addr fc01e000 [fault reason 06] PTE
Read access is not set
avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3
avril 10 11:46:25 dell-m4700 kernel: DMAR: [DMA Read] Request device
[01:00.0] PASID ffffffff fault addr fc045000 [fault reason 06] PTE
Read access is not set
avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3
avril 10 11:46:25 dell-m4700 kernel: DMAR: [DMA Read] Request device
[01:00.0] PASID ffffffff fault addr fc06a000 [fault reason 06] PTE
Read access is not set
avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3
```
01:00.0 is the nvidia chip here, where my 2nd screen is connected.
```
$ lspci | grep 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K2000M] (rev a1)
```
The wiring of my laptop (Dell M4700) GPU setup (optimus) makes it mandatory when you're using eDP outputs to use the nvidia chip.
```
$ sudo ls /sys/class/drm/card0/ | grep card
card0-LVDS-1
card0-VGA-1
$ sudo ls /sys/class/drm/card1/ | grep card
card1-DP-1
card1-DP-2
card1-DP-3
```
```
$ xrandr
Screen 0: minimum 16 x 16, current 5360 x 1665, maximum 32767 x 32767
XWAYLAND1 connected 1920x1080+3440+585 (normal left inverted right x axis y axis) 340mm x 190mm
1920x1080 59.96*+
XWAYLAND2 connected 3440x1440+0+0 (normal left inverted right x axis y axis) 800mm x 340mm
3440x1440 59.94*+
```
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/10Setting a cloned/spoofed MAC (for a wired connection) via GNOME Settings does...2024-03-25T15:03:18ZGNSetting a cloned/spoofed MAC (for a wired connection) via GNOME Settings doesn't workEntering a spoofed MAC in the identity tab of a network connection profile in GNOME Settings doesn't work - after hitting Apply then re-opening the settings dialogue window, the "Cloned MAC" box contains the hardware MAC instead of the p...Entering a spoofed MAC in the identity tab of a network connection profile in GNOME Settings doesn't work - after hitting Apply then re-opening the settings dialogue window, the "Cloned MAC" box contains the hardware MAC instead of the previously entered spoofed MAC.
It doesn't matter if this is done when the connection is active or not.
Running `nmcli show [connection name] | grep 802-3-ethernet.cloned-mac-address` shows that `802-3-ethernet.cloned-mac-address` has been populated for the connection, but with the hardware MAC instead of the chosen spoofed MAC.
`nmcli modify [connection name] 802-3-ethernet.cloned-mac-address [some mac]` works correctly.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3348Trash: when auto empty trash is enabled, Nautilus can't open the trash settin...2024-03-25T10:56:00ZAutomeris naranjaTrash: when auto empty trash is enabled, Nautilus can't open the trash settings section of GNOME Settings## Affected version
- nautilus-45.2.1-1.fc39.x86_64 (can't test nightly flatpak because of https://gitlab.gnome.org/GNOME/nautilus/-/issues/3343)
## Steps to reproduce
1. Go to GNOME Settings > Privacy > File History & Trash
2. Enable "...## Affected version
- nautilus-45.2.1-1.fc39.x86_64 (can't test nightly flatpak because of https://gitlab.gnome.org/GNOME/nautilus/-/issues/3343)
## Steps to reproduce
1. Go to GNOME Settings > Privacy > File History & Trash
2. Enable "Automatically Delete Trash Content"
3. Open Nautilus and go to the Trash view
4. Click in the "Settings" button from the "Items in trash older than..." banner
## Seen behavior
The File History & Trash section of Settings won't appear.
This is broken since GNOME 45, which introduced the new Privacy panel (https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1819) with subpages. In GNOME 46, https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2038 / https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2288 added the possibility to open panel subpages, but ~~it seems that only the System panel is currently supported~~ the Privacy panel is yet to be supported.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1124Automatic hours field shifting changes the minutes field's values2024-03-25T07:52:10ZJeff FortinAutomatic hours field shifting changes the minutes field's valuesIn a new event in the event editor dialog, switch the event from "All day" to time based, and then...
Scenario A:
1. Set the start time to 13h 15
2. Set the end time to 14h 28
3. Push the "+" button on the start hour twice, so that 13h ...In a new event in the event editor dialog, switch the event from "All day" to time based, and then...
Scenario A:
1. Set the start time to 13h 15
2. Set the end time to 14h 28
3. Push the "+" button on the start hour twice, so that 13h becomes 15h and so that the end hour becomes 16h...
Result: the end time's minutes field becomes "15", instead of remaining as "28"
Scenario B:
1. Set the start time to 18h 15
2. Set the end time to 19h 28
3. Push the "-" button on the end hour twice, so that 19h becomes 17h and so that the start hour becomes 16h...
Result: the end time's minutes field becomes "15", instead of remaining as "28"
---
In both cases, the minutes field should remain untouched by the hours field's noodly appendage.Spaghetti SenseiSpaghetti Senseihttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1123Do not shift start time when setting an end time that ends after midnight wit...2024-03-25T07:52:10ZJeff FortinDo not shift start time when setting an end time that ends after midnight with a smaller hour numberThis is a follow-up to #91, and related to #1121.
## Reproduction instructions
To reproduce, especially with !376, in 24-hour time format mode:
1. Create an event with the event editor dialog, switch from "All day" to time-based
2. Se...This is a follow-up to #91, and related to #1121.
## Reproduction instructions
To reproduce, especially with !376, in 24-hour time format mode:
1. Create an event with the event editor dialog, switch from "All day" to time-based
2. Set the start hour to `21`; notice the end time gets automatically set to `22` hours
3. Set the end hour to `02` (two in the morning)
(Note that you could use different times, such as 17h start time then setting 01h end time, you'd then end up with a 00h start time... but I wanted to illustrate the example simply with an evening time like 21h.)
## Actual result
Start time gets auto-changed to `01` while end date is considered today's 02h (instead of the next day's 02h).
This is because the event editor tries to guess the user's intent, so it guessed the user wanted to shift the event back in time to schedule it sooner, as an "end time before the start time" does not make sense. There are _some_ situations where it makes sense for it to try to do so (for example if you had an event scheduled from 16h to 18h, and then you change the end time to 15h so its start time becomes 13h, that kinda makes sense because surely you meant to just shift the event backwards rather than have an event from 16h today until 15h tomorrow)...
## Expected result
Under certain circumstances (big time difference? evening start times?), start time should remain untouched (in this case, `21`) and end date should be bumped to next day with the end time the user has provided.
## Questions and caveats
The big question is, when/how to decide the auto-adjustment logic? Where/how do you draw the line between that "overnight" situation and something like "I want to shift/reschedule an event backwards within the day" (ex: shift an event that was scheduled from 21h to 23h, back to an event that happens between 11h and 13h)?
* Based on the time of the day where the event start time was set (ex: make a distinction between events that started in the evening, vs earlier events)? Or maybe a combination of "start time is between 18h and 24h, end time is between 00h and 12h = considered an overnight event"?
* Based on the amount of hours shifted (time difference being bigger than 8 hours? time difference between bigger than 2x the previous duration of the event?)...?
Other potential caveat: how to handle this stuff with the 12-hours "AM / PM" system (because it's tricky enough with the 24-hour format already...)?
## Alternate solution
...or just don't try to guess / never auto-shift the start times and start dates for the user, and whenever the dialog encounters a nonsensical "end time/date is before start time/date" situation, highlight in red the problematic fields + disable (make insensitive) the "Done" button until the situation has been corrected by the user? This is Google Calendar's approach:
* It only adjusts the end date "if necessary for #1121" when it means adding an extra day to the end date;
* It never touches the start time/date when changing the end time/date;
* If the user somehow manages to do something nonsensical, like _setting the end time before the end date (in which case it adds an extra day to the end date) AND re-setting the end date to the previous day,_ then Google Calendar blocks the "Save" button and marks the end time & date fields in red until the user corrects them:
![google_calendar_date_and_hours_shifting_heuristic](/uploads/a33afdaa7574ff57be83c9a24914fd20/google_calendar_date_and_hours_shifting_heuristic.mp4)Spaghetti SenseiSpaghetti Senseihttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1121Setting end time to 23h when start time is 23h should not bump end date to ne...2024-03-25T07:52:10ZJeff FortinSetting end time to 23h when start time is 23h should not bump end date to next day until you type an end time after midnightThis is a very minor corner-case scenario, but it causes problems / user inattention errors when scheduling time-based events that last "between 23h00 and 23h59" (ex: a half-hour event at 23h).
## To reproduce
1. Create an event using ...This is a very minor corner-case scenario, but it causes problems / user inattention errors when scheduling time-based events that last "between 23h00 and 23h59" (ex: a half-hour event at 23h).
## To reproduce
1. Create an event using the advanced event editor dialog
1. Toggle off "All day" to convert to a time-based event
1. Type "23" as the starting hour, leave minutes to "00"
1. Type "23" as the ending hour (before setting the minutes)
## Actual results
End date is bumped 1 day into the future
## Expected results
In the very specific case of events that start at 23:xx and end at 23:yy, we should not auto-increment the end time (and thus end date) by 1 hour; we can pretty safely assume the user meant to do a time-based event that is within the same day and that they will set the minutes end time to sometime before 23h59. It is much less likely that the user actually meant to create an event from "23h today to 23h next day".
In other situations (ex: start/end times that are any number _other_ than `23`), GNOME Calendar can safely do its usual calculations to auto-increment the end time by 1 hour after the start time.
---
This is a successor to issue #91, and kind of related (but much less messed up) to issue #1120 (12-hour time issue), and #393 (default values issue).Spaghetti SenseiSpaghetti Senseihttps://gitlab.gnome.org/GNOME/gvfs/-/issues/725Remote SMB repository - A mount operation succeeded but location is still una...2024-03-25T07:38:08ZLukas BacovskyRemote SMB repository - A mount operation succeeded but location is still unavailable<!--
Report an Issue
If possible and potentially relevant, please supply the following information
- Pika Backup version
- Installation method (Flathub, distribution package)
- Used Linux distribution and version
- Repository location ...<!--
Report an Issue
If possible and potentially relevant, please supply the following information
- Pika Backup version
- Installation method (Flathub, distribution package)
- Used Linux distribution and version
- Repository location (hard drive, ssh-server, smb-server, etc)
-->
**Pika Backup version:** 0.7.0, 0.7.1
**Installation method:** Flathub
**Used Linux distribution and version:** Fedora 39
**Repository location:** Samba server on my Synology NAS (in the same network)
When I try to set new remote samba backup repository - smb://lukas@192.168.0.15/home/Backups, Pika shows "A mount operation succeeded but location is still unavailable". But i can see the samba share mounted in Nautilus and I can even write to it. I don't know if there some error on my side like permissions error or something but the same samba share works fine with Deja Dup.
Logs:
[pika.log](/uploads/7e29cdf1c835443e2bc66c7b9c73cc76/pika.log)https://gitlab.gnome.org/GNOME/nautilus/-/issues/3172Banner with enabled "Empty Trash" button even when there is no trash2024-03-25T01:59:53ZUrtsi SantsiBanner with enabled "Empty Trash" button even when there is no trash<!--
Please test if the issue has already been fixed by installing the latest testing version.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/se...<!--
Please test if the issue has already been fixed by installing the latest testing version.
It can be installed alongside 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 the Terminal or Console app:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3. Launch the development version (normal Files logo with yellow and black stripes), e.g. with:
flatpak run org.gnome.NautilusDevel
-->
# Affected Version
- Version: 46.alpha.0-8d1b02c12 (NautilusDevel flatpak), couldn't test it with stable due to #3171
- Distribution: Fedora Workstation 39
- Happens with development Flatpak: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
Open trash folder that is empty or empty it if it is full.
# Expected Behavior
There isn't a banner with "Empty Trash..." button or the button is disabled.
# Actual Behavior
There is a banner with "Empty Trash..." enabled button and clicking it opens the dialog.https://gitlab.gnome.org/GNOME/gimp/-/issues/7500Icons disappearing in the layer list when using System theme2024-03-24T20:35:39ZenzedrailmapsIcons disappearing in the layer list when using System theme### Environment/Versions
- GIMP version: 2.99.8 and issue does not occur in 2.10.xx
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> flatpak beta
- Operating S...### Environment/Versions
- GIMP version: 2.99.8 and issue does not occur in 2.10.xx
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> flatpak beta
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Linux (Debian 11 kde)
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
When the layers appear in the layer list. The icon that shows the layer visibility is hidden even when the layer is visible (unless the layer is selected)
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
![Screenshot_2021-11-15_20-57-32](/uploads/0b1e34ec6a109c1a524d94d42e10a847/Screenshot_2021-11-15_20-57-32.png)
![Screenshot_2021-11-15_20-58-30](/uploads/d8b8c6bb0d959076f49e75d7ff9bc21a/Screenshot_2021-11-15_20-58-30.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Randomly
Reproduction steps:
1. Unknown
2.
3.
…
Expected result: all visible layers show the visibility icon (eye symbol) in the layer list
Actual result: icons are not visible unless the layer is currently selected in the layer list.
### Additional information
If you have a backtrace for a crash or a warning, paste it here.3.0https://gitlab.gnome.org/GNOME/gimp/-/issues/5089[System theme leak] Using 'Open with GIMP' on Plasma messes up the theme2024-03-24T20:29:25ZMarco Hufnagel[System theme leak] Using 'Open with GIMP' on Plasma messes up the theme- GIMP version: 2.10.18 - Flatpak
- Flatpak version: 1.7.2 (also tested with other versions)
- Distro: KDE Neon User edition
- Plasma version: 5.18.5
Im am using the latest flatpak version of GIMP and when opening up the app normally, e...- GIMP version: 2.10.18 - Flatpak
- Flatpak version: 1.7.2 (also tested with other versions)
- Distro: KDE Neon User edition
- Plasma version: 5.18.5
Im am using the latest flatpak version of GIMP and when opening up the app normally, everything is working great. However, when I right-click on a file and choose 'open with GIMP', the applications opens with a strange theming, which looks like this:
![image](/uploads/70f00a267156c6bd99ad8bd14db406ef/image.png)
The same also happens when I use the terminal command
```flatpak run org.gimp.GIMP <filename.png>```
I also checked both the deb file and the snap version of GIMP, which are both free of this issue.https://gitlab.gnome.org/GNOME/gimp/-/issues/5173Space invasion: GIMP color palettes produce wrong colors when changing RGB wo...2024-03-24T19:58:25ZElle StoneSpace invasion: GIMP color palettes produce wrong colors when changing RGB working spacesIn GIMP-2.99 (and GIMP-2.10), an RGB color palette (for painting, not talking about Indexed image colormap palettes) only produces the intended colors for images in the RGB color space in which the RGB color palette was produced. So for ...In GIMP-2.99 (and GIMP-2.10), an RGB color palette (for painting, not talking about Indexed image colormap palettes) only produces the intended colors for images in the RGB color space in which the RGB color palette was produced. So for example, a palette of colors made for an sRGB image produces wrong colors for ClayRGB images, Rec.2020 images, and so on, and vice versa.
The space invasion won't be complete until an artist or photographer (photographers do use color palettes, for example when recoloring a black and white image) can set up and use a palette of colors without having to redo the palette for every RGB working space they might want to use.
Using LCh or (XYZ/Lab/xyY/etc) as the color space for holding color palette colors would help with this problem of how to have "AnyRGB" color palettes. I took my code for high bit depth color palettes from #https://gitlab.gnome.org/GNOME/gimp/-/issues/1328 and modified it further to allow loading and saving LCh color palettes in my "CCE" version of GIMP-2.10.
There is still the problem that my current code converts between LCh and RGB when loading, importing, and saving a palette, so the palette only works for the RGB color space that was active when the image was opened, or in sRGB if no image was opened when the palette was loaded.
My current workaround is to put my LCh palettes in a folder outside of where GIMP looks for palettes (in my case in the prefix in a folder called "config" in a subfolder called "palette"), open an image, and then import the desired palette(s), so the palette is created in the RGB working space of the image. This of course requires only working in one RGB working space for any given editing session, and deleting anything in the "palette" folder upon restarting GIMP.
If anyone expresses an actual interest with intent to look at my high bit depth LCh color palette code, put a note here and I'll port the code to GIMP-2.99. But please don't ask if you actually aren't really interested :) .
I think it would be relatively easy to put a line in the palette load/save code to indicate what color space/model to use when loading/saving any given high bit depth color palette. I haven't actually written any code to do this as personally LCh is the only color space that I use for palettes. But surely a single line in the palette with appropriate babl fishes defined for the conversion to RGB would do the trick.
One way to "Change the palette RGB values when changing the image RGB working space" might be to reload the palette when the working space changes. I haven't figured out where such code might go.https://gitlab.gnome.org/GNOME/eog/-/issues/312PNG files display as default missing image in Image Gallery and clicking on o...2024-03-24T18:34:14ZHaydon RyanPNG files display as default missing image in Image Gallery and clicking on one crashes EOGSteps to reproduce:
**Setup:**
I have a directory of pictures with:
- 13 .PNG files
- 1 .png files
- 2 .JPG files
**Test 1:**
double click on a PNG file in nautilus to open eye of gnome.
hamburger menu -> show -> image gallery
The on...Steps to reproduce:
**Setup:**
I have a directory of pictures with:
- 13 .PNG files
- 1 .png files
- 2 .JPG files
**Test 1:**
double click on a PNG file in nautilus to open eye of gnome.
hamburger menu -> show -> image gallery
The one png that is shown in the gallery view has a default placeholder.
Pressing next crashes EOG.
**Test 2:**
double click on a PNG file in nautilus to open eye of gnome.
hamburger menu -> show -> image gallery
click a jpg in image gallery.
click the png in image gallery.
EOG crashes.
**Test 2:**
run `eog image-file.PNG`
repeat test 2
```$ eog IMG_0027.PNG
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.983: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.984: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:35.984: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.172: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.172: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.172: g_content_type_get_description: assertion 'type != NULL' failed
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.174: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.174: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.215: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.215: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): Gtk-WARNING **: 10:17:36.220: Attempting to add 'smb://galaxy/data/Pictures/Van%20Life/IMG_0027.PNG' to the list of recently used resources, but no MIME type was defined
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.764: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.764: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.772: GFileInfo created without standard::content-type
(eog:14236): GLib-GIO-CRITICAL **: 10:17:36.772: file ../glib/gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not be reached
(eog:14236): GLib-GObject-CRITICAL **: 10:17:39.962: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:39.962: instance with invalid (NULL) class pointer
(eog:14236): GLib-GObject-CRITICAL **: 10:17:39.962: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:39.962: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:39.964: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:39.965: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.162: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.178: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.180: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.188: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.228: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.244: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.260: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.270: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.276: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.286: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.293: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.302: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.308: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.318: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.326: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.334: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.342: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.350: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.358: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.366: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.374: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.384: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.392: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.398: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.406: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.414: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.422: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.430: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.446: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.480: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.504: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:43.564: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:44.215: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
(eog:14236): GLib-GObject-CRITICAL **: 10:17:44.402: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed
**
EOG:ERROR:../eog/src/eog-window.c:1589:handle_image_selection_changed_cb: assertion failed: (EOG_IS_IMAGE (image))
Bail out! EOG:ERROR:../eog/src/eog-window.c:1589:handle_image_selection_changed_cb: assertion failed: (EOG_IS_IMAGE (image))
Aborted (core dumped)
```
journalctl -f:
```
Mar 02 10:17:05 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x5e46f11f76f0] is on because it needs an allocation.
Mar 02 10:17:05 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x5e46e7712c70] is on because it needs an allocation.
Mar 02 10:17:16 falcon rtkit-daemon[1211]: Supervising 8 threads of 5 processes of 1 users.
Mar 02 10:17:16 falcon rtkit-daemon[1211]: Supervising 8 threads of 5 processes of 1 users.
Mar 02 10:17:20 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x5e46f11f76f0] is on because it needs an allocation.
Mar 02 10:17:20 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x5e46e7712c70] is on because it needs an allocation.
Mar 02 10:17:21 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x5e46f11f76f0] is on because it needs an allocation.
Mar 02 10:17:21 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x5e46e7712c70] is on because it needs an allocation.
Mar 02 10:17:33 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x5e46ecff3340] is on because it needs an allocation.
Mar 02 10:17:33 falcon gnome-shell[1547]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x5e46e856fca0] is on because it needs an allocation.
Mar 02 10:17:36 falcon gnome-shell[1547]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1e00007
Mar 02 10:17:44 falcon systemd[1]: Started Process Core Dump (PID 14255/UID 0).
Mar 02 10:17:44 falcon systemd-coredump[14256]: [🡕] Process 14236 (eog) of user 1000 dumped core.
Stack trace of thread 14236:
#0 0x0000792a02aab32c n/a (libc.so.6 + 0x8d32c)
#1 0x0000792a02a5a6c8 raise (libc.so.6 + 0x3c6c8)
#2 0x0000792a02a424b8 abort (libc.so.6 + 0x244b8)
#3 0x0000792a034700ee n/a (libglib-2.0.so.0 + 0x1e0ee)
#4 0x0000792a034d1220 g_assertion_message_expr (libglib-2.0.so.0 + 0x7f220)
#5 0x0000792a038553c4 n/a (libeog.so + 0x463c4)
#6 0x0000792a035b26c0 g_closure_invoke (libgobject-2.0.so.0 + 0x146c0)
#7 0x0000792a035e0a36 n/a (libgobject-2.0.so.0 + 0x42a36)
#8 0x0000792a035d1a42 n/a (libgobject-2.0.so.0 + 0x33a42)
#9 0x0000792a035d1c77 g_signal_emit_valist (libgobject-2.0.so.0 + 0x33c77)
#10 0x0000792a035d1d34 g_signal_emit (libgobject-2.0.so.0 + 0x33d34)
#11 0x0000792a02dbfc0f n/a (libgtk-3.so.0 + 0x1bfc0f)
#12 0x0000792a02c8c6cd n/a (libgtk-3.so.0 + 0x8c6cd)
#13 0x0000792a035b26c0 g_closure_invoke (libgobject-2.0.so.0 + 0x146c0)
#14 0x0000792a035e10ea n/a (libgobject-2.0.so.0 + 0x430ea)
#15 0x0000792a035d1335 n/a (libgobject-2.0.so.0 + 0x33335)
#16 0x0000792a035d1c77 g_signal_emit_valist (libgobject-2.0.so.0 + 0x33c77)
#17 0x0000792a035d1d34 g_signal_emit (libgobject-2.0.so.0 + 0x33d34)
#18 0x0000792a02f54cd5 n/a (libgtk-3.so.0 + 0x354cd5)
#19 0x0000792a02deec6b n/a (libgtk-3.so.0 + 0x1eec6b)
#20 0x0000792a02def797 gtk_main_do_event (libgtk-3.so.0 + 0x1ef797)
#21 0x0000792a02957b77 n/a (libgdk-3.so.0 + 0x33b77)
#22 0x0000792a029b0438 n/a (libgdk-3.so.0 + 0x8c438)
#23 0x0000792a034abf69 n/a (libglib-2.0.so.0 + 0x59f69)
#24 0x0000792a0350a3a7 n/a (libglib-2.0.so.0 + 0xb83a7)
#25 0x0000792a034aa162 g_main_context_iteration (libglib-2.0.so.0 + 0x58162)
#26 0x0000792a036dfb66 g_application_run (libgio-2.0.so.0 + 0xdfb66)
#27 0x00005a0de9f5a173 main (eog + 0x1173)
#28 0x0000792a02a43cd0 n/a (libc.so.6 + 0x25cd0)
#29 0x0000792a02a43d8a __libc_start_main (libc.so.6 + 0x25d8a)
#30 0x00005a0de9f5a265 _start (eog + 0x1265)
Stack trace of thread 14239:
#0 0x0000792a02b190bf __poll (libc.so.6 + 0xfb0bf)
#1 0x0000792a0350a2f6 n/a (libglib-2.0.so.0 + 0xb82f6)
#2 0x0000792a034aa162 g_main_context_iteration (libglib-2.0.so.0 + 0x58162)
#3 0x00007929fe79cfde n/a (libdconfsettings.so + 0x5fde)
#4 0x0000792a034dda45 n/a (libglib-2.0.so.0 + 0x8ba45)
#5 0x0000792a02aa955a n/a (libc.so.6 + 0x8b55a)
#6 0x0000792a02b26a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 14238:
#0 0x0000792a02b190bf __poll (libc.so.6 + 0xfb0bf)
#1 0x0000792a0350a2f6 n/a (libglib-2.0.so.0 + 0xb82f6)
#2 0x0000792a034aa162 g_main_context_iteration (libglib-2.0.so.0 + 0x58162)
#3 0x0000792a034aa1b2 n/a (libglib-2.0.so.0 + 0x581b2)
#4 0x0000792a034dda45 n/a (libglib-2.0.so.0 + 0x8ba45)
#5 0x0000792a02aa955a n/a (libc.so.6 + 0x8b55a)
#6 0x0000792a02b26a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 14240:
#0 0x0000792a02b190bf __poll (libc.so.6 + 0xfb0bf)
#1 0x0000792a0350a2f6 n/a (libglib-2.0.so.0 + 0xb82f6)
#2 0x0000792a034acb97 g_main_loop_run (libglib-2.0.so.0 + 0x5ab97)
#3 0x0000792a0371219c n/a (libgio-2.0.so.0 + 0x11219c)
#4 0x0000792a034dda45 n/a (libglib-2.0.so.0 + 0x8ba45)
#5 0x0000792a02aa955a n/a (libc.so.6 + 0x8b55a)
#6 0x0000792a02b26a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 14237:
#0 0x0000792a02b2488d syscall (libc.so.6 + 0x10688d)
#1 0x0000792a03505337 g_cond_wait (libglib-2.0.so.0 + 0xb3337)
#2 0x0000792a034771b4 n/a (libglib-2.0.so.0 + 0x251b4)
#3 0x0000792a034dface n/a (libglib-2.0.so.0 + 0x8dace)
#4 0x0000792a034dda45 n/a (libglib-2.0.so.0 + 0x8ba45)
#5 0x0000792a02aa955a n/a (libc.so.6 + 0x8b55a)
#6 0x0000792a02b26a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 14241:
#0 0x0000792a02b2488d syscall (libc.so.6 + 0x10688d)
#1 0x0000792a03505337 g_cond_wait (libglib-2.0.so.0 + 0xb3337)
#2 0x0000792a03833570 n/a (libeog.so + 0x24570)
#3 0x0000792a034dda45 n/a (libglib-2.0.so.0 + 0x8ba45)
#4 0x0000792a02aa955a n/a (libc.so.6 + 0x8b55a)
#5 0x0000792a02b26a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 14243:
#0 0x0000792a02b2488d syscall (libc.so.6 + 0x10688d)
#1 0x0000792a03505337 g_cond_wait (libglib-2.0.so.0 + 0xb3337)
#2 0x0000792a034771b4 n/a (libglib-2.0.so.0 + 0x251b4)
#3 0x0000792a0347721c g_async_queue_pop (libglib-2.0.so.0 + 0x2521c)
#4 0x0000792a01a71d08 n/a (libpangoft2-1.0.so.0 + 0x8d08)
#5 0x0000792a034dda45 n/a (libglib-2.0.so.0 + 0x8ba45)
#6 0x0000792a02aa955a n/a (libc.so.6 + 0x8b55a)
#7 0x0000792a02b26a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 14244:
#0 0x0000792a02b2488d syscall (libc.so.6 + 0x10688d)
#1 0x0000792a03505d13 g_cond_wait_until (libglib-2.0.so.0 + 0xb3d13)
#2 0x0000792a03477185 n/a (libglib-2.0.so.0 + 0x25185)
#3 0x0000792a034772e7 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x252e7)
#4 0x0000792a034e03be n/a (libglib-2.0.so.0 + 0x8e3be)
#5 0x0000792a034dda45 n/a (libglib-2.0.so.0 + 0x8ba45)
#6 0x0000792a02aa955a n/a (libc.so.6 + 0x8b55a)
#7 0x0000792a02b26a3c n/a (libc.so.6 + 0x108a3c)
ELF object binary architecture: AMD x86-64
Mar 02 10:17:44 falcon systemd[1]: systemd-coredump@6-14255-0.service: Deactivated successfully.
Mar 02 10:19:19 falcon rtkit-daemon[1211]: Supervising 8 threads of 5 processes of 1 users.
Mar 02 10:19:19 falcon rtkit-daemon[1211]: Supervising 8 threads of 5 processes of 1 users.
```
Happy to do further testing.
System Info:
- OS: Arch Linux x86_64
- Kernel: 6.7.6-arch1-1
- eog: 45.2-1https://gitlab.gnome.org/GNOME/gimp/-/issues/2929Toolbox "Change FG tool", sometimes LCh sliders can't be moved independently2024-03-24T15:45:27ZElle StoneToolbox "Change FG tool", sometimes LCh sliders can't be moved independentlyFor GIMP-2.99, when using the FG/BG tool to dial in a color, when starting with the LCh color L=C=h=0 (solid black, R=G=B=0):
* Dialing in L=50 (leaving the other channels alone) makes the LCh hue reset itself to h=142-ish.
* Resettin...For GIMP-2.99, when using the FG/BG tool to dial in a color, when starting with the LCh color L=C=h=0 (solid black, R=G=B=0):
* Dialing in L=50 (leaving the other channels alone) makes the LCh hue reset itself to h=142-ish.
* Resetting h to 0 and dialing in C=20, the hue again reset itself to a hue other than 0, on my last try it reset to 4.
* Going back and changing "L" makes the other sliders change again.
Similar oddities happen in GIMP-2.10, so this likely isn't a result of code changes for "anyrgb".
This "resetting" of the hue when changing the Lightness and Chroma absolutely shouldn't happen. And modifying L shouldn't also make one or both of the other LCh sliders move. It should be possible to start with solid black L=C=h=0, and dial in L=50, with C and h staying at 0. And then it should be possible to set C to a number greater than 0, and still have the hue stay at 0. In other words, modifying any one slider should *not* cause the other sliders to move.
The problem also affects the "FG/BG Color" docker sliders, though the exact numbers that pop up vary from the Toolbox Change Foreground tool. Also, in the FG/BG tool, sometimes moving the LCh sliders to be zero makes one or more of the RGB channels read as negative zero.
This slider resetting might be related to the problem that blending a top color layer using LCh Chroma over a bottom gray layer sometimes produces unexpected hue shifts. Note in the 2.10 screenshot below, the hue shift just from the blend - the Sample Points show the blended RGB and LCh. The color picker is set to only read the actual color layer rather than the merged result. Both color readouts should have the same hue and Chroma, but notice the blended hue is different from the hue of the actual layer:
![7](/uploads/2aa821d50323c98759a67ad71760d443/7.png)
This is on Debian Sid, updated today, and using babl/GEGL/both versions of GIMP also updated today.3.0 RC1https://gitlab.gnome.org/GNOME/nautilus/-/issues/2963Files search does not work for some files2024-03-24T15:16:44ZJulien FalqueFiles search does not work for some filesFile search in Gnome Activities or using Files' search bar seems to fail for some files. For example, I have a file at `/home/julien/Documents/signature.png` but the search can't find it.
`tracker3` finds it:
```console
❯ tracker3 searc...File search in Gnome Activities or using Files' search bar seems to fail for some files. For example, I have a file at `/home/julien/Documents/signature.png` but the search can't find it.
`tracker3` finds it:
```console
❯ tracker3 search signature.png
Results:
file:///part/data/Users/Julien/Documents/signature.png
signature.png
```
But a D-Bus call doesn't:
```console
❯ gdbus call --session --dest org.gnome.Nautilus --object-path /org/gnome/Nautilus/SearchProvider --method org.gnome.Shell.SearchProvider2.GetInitialResultSet '["signature.png"]'
(@as [],)
```
`tracker3` returns a different path because `/home/julien/Documents` is a symlink to `/part/data/Users/Julien/Documents`, which is on a separate NTFS partition, could this be the culprit?
I'm on Arch Linux with Files v44.1.https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/278Birthdates import with the wrong date.2024-03-24T14:30:31ZLes ZsamparBirthdates import with the wrong date.<!--
Please check first if your problem isn't already listed in the issue tracker
and/or if it's fixed in the latest stable version.
-->
# Affected version
- GNOME Contacts version: 43.0
- Application provider: distribution
- Relat...<!--
Please check first if your problem isn't already listed in the issue tracker
and/or if it's fixed in the latest stable version.
-->
# Affected version
- GNOME Contacts version: 43.0
- Application provider: distribution
- Related info:
<!-- Fedora 37-->
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Import vcf file, which includes birthdates for contacts
2. compare dates between import file and Gnome Contacts
3. Date in Gnome contacts is out by 1 day.
# Current behavior
<!-- birthdates in contacts file import with the wrong date. -->
# Expected behavior
<!-- birthdates should import with the correct date -->
# 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
-->
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/gimp/-/issues/7092Text location incorrect when exporting2024-03-24T13:19:41ZChad SwiftText location incorrect when exporting### Environment/Versions
- GIMP version: 2.10.24 (rev 3)
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Installer from gimp.org
- Operating System: <!--[Windo...### Environment/Versions
- GIMP version: 2.10.24 (rev 3)
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Installer from gimp.org
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
When exporting, text layers are not set in same location, relative to the rest of the image layers. Verrified issue in PDF when opened in Edge, Adobe Reader, and Inkscape.
Possible issue is more frequent when there are hidden layers.
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Frequently
Reproduction steps:
1. Use text mixed with shapes and images in separate layers
2. export as pdf while embedding fonts and using vector graphics where available
3. end PDF does not look like
…
Expected result:
Actual result:
### Additional information
If you have a backtrace for a crash or a warning, paste it here.https://gitlab.gnome.org/GNOME/gimp/-/issues/2294Text rendering when exporting to PDF has spacing removed, is bolded, occaison...2024-03-24T13:19:22ZGhost UserText rendering when exporting to PDF has spacing removed, is bolded, occaisonally in wrong placeGIMP version: 2.10
Operating System: Windows 10
Package: Installer from gimp.org
Trying to export a PDF resume and I noticed an issue I was having with GIMP 2.8, so I updated to 2.10 but the same issue persists. On screen in GIMP, t...GIMP version: 2.10
Operating System: Windows 10
Package: Installer from gimp.org
Trying to export a PDF resume and I noticed an issue I was having with GIMP 2.8, so I updated to 2.10 but the same issue persists. On screen in GIMP, the text looks fine, however when exporting to PDF the text becomes extremely compacted as if all or most of the leading (letter spacing) is removed. This exported result doesn't change even if I increase the actual letter spacing in the file.
Also, the text itself renders bolder than what appears in the GIMP file. As a designer, this is a really serious issue.
Additionally when exporting, sometimes certain text is rendered in the wrong place seemingly at random, but it tends to render the text in the same wrong spot when exporting to a PDF multiple times.
It renders wrong in Microsoft Edge, Firefox, and Acrobat.
![Comparison__2_](/uploads/df7e855fb7f006b8a703a3191c8a2537/Comparison__2_.png)
![Comparison](/uploads/8f6ae1f0cb96219646ddc55c1c811b75/Comparison.png)
Is the bug reproducible? [Always]
Reproduction steps:
1.Create new file
2.Create text
3.Export to PDF
…
Expected result: Text to render appropriately
Actual result: Text renders with letter spacing reduced or removed and text appears to be bolder than when viewing in GIMP itself, sometimes in the wrong placeIdriss FekirIdriss Fekir