GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2023-11-03T06:40:33Zhttps://gitlab.gnome.org/GNOME/geary/-/issues/204Disabling Mark as Read Automatically2023-11-03T06:40:33ZAxel UlrichDisabling Mark as Read AutomaticallyThis is a feature request as discussed here:
https://mail.gnome.org/archives/geary-list/2019-January/msg00002.html
To summarize the request from the discussion:
Preferences should have a new option:
"Mark messages read when replying, ...This is a feature request as discussed here:
https://mail.gnome.org/archives/geary-list/2019-January/msg00002.html
To summarize the request from the discussion:
Preferences should have a new option:
"Mark messages read when replying, archiving, or taking other actions"
If the option is NOT selected, conversations are marked as read when they are loaded and reading progresses, wich is the current behavior.
If the option IS selected, then taking any action (replying, forwarding, archiving, trashing or junking) will mark the message that the action is taken on and all previous messages in the conversation as read.https://gitlab.gnome.org/GNOME/gnome-weather/-/issues/20Expose the 'Feels like' temperature below the real temperature2023-05-28T11:23:25ZAmr IbrahimExpose the 'Feels like' temperature below the real temperatureI find the 'feels like' temperature useful and I always look for it on my weather app on Android.
gnome-shell shows the 'feels like' temperature in the date menu, but it will be removed in a future release:
https://gitlab.gnome.org/GNOM...I find the 'feels like' temperature useful and I always look for it on my weather app on Android.
gnome-shell shows the 'feels like' temperature in the date menu, but it will be removed in a future release:
https://gitlab.gnome.org/GNOME/gnome-shell/commit/5dedb97fcc1e1bf430b4d494275e03e5ef5dfa3d#362c36af8414ec96126b78f027754e91275dc1b0_317_311
So please expose the 'feels like' temperature below the real temperature in gnome-weather.https://gitlab.gnome.org/GNOME/nautilus/-/issues/902Indicate if searching Full Text or not2024-02-09T02:11:19ZXavier JohnsonIndicate if searching Full Text or not### Use cases
When performing a Search with Ctrl+F / the magnifying glass icon, it is possible to search by either "Full Text" or "File Name", but there is no visual indicator of which search type is being performed. The only way to see ...### Use cases
When performing a Search with Ctrl+F / the magnifying glass icon, it is possible to search by either "Full Text" or "File Name", but there is no visual indicator of which search type is being performed. The only way to see the current search type is to click on the drop-down arrow on the search bar. As a result, it is easy to forget which type is being used, and to think that there are no results matching a search query, when in reality the search type was really just the opposite of the one expected to be in use.
### Desired behavior
There should be some kind of visual indicator somewhere on the titlebar indicating what the current search type is. One idea is to place an annotation on the search bar for the current search type, like how there are annotations for the search date range & filetype specifications.
### Benefits of the solution
This would make it easier to know at-a-glance what is being searched for by a search operation, thereby reducing the risk of accidentally searching for a file name when Full Text searching is on, or for file content when File Name searching is on.
### Possible drawbacks
Adding a visual cue for the search type could make the UI more cluttered, wherever it ends up going. It could also be a waste of space for users who don't change the search type often and don't need to care about what the search type is.https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/48Sync with GNOME Extensions Account2019-02-13T11:16:10ZRicardo RodriguesSync with GNOME Extensions AccountThe idea is simple, yet don't see an issue discussing it.
Use GNOME Extensions Account (that should be GNOME Account) to sync definitions and user info across devices. This would be similar to Windows and Apple account behavior.
It sho...The idea is simple, yet don't see an issue discussing it.
Use GNOME Extensions Account (that should be GNOME Account) to sync definitions and user info across devices. This would be similar to Windows and Apple account behavior.
It should allow synchronization of extensions, background wallpapers, system configuration (mouse clicks, window buttons location, etc.) and possibly other Online Accounts (although this would probably be too much).
Think of icloud.com as the perfect example of content to sync.
What do you think?https://gitlab.gnome.org/GNOME/mutter/-/issues/461Clutter & Cogl 2.02024-01-08T08:14:08ZGeorges Basile Stavracas NetoClutter & Cogl 2.0This is a tracker issue for us to keep moving and working on Clutter & Cogl 2.0 plans. Relevant links:
* https://wiki.gnome.org/Projects/Clutter/Roadmap
* https://wiki.gnome.org/Projects/Clutter/ApocalypsesThis is a tracker issue for us to keep moving and working on Clutter & Cogl 2.0 plans. Relevant links:
* https://wiki.gnome.org/Projects/Clutter/Roadmap
* https://wiki.gnome.org/Projects/Clutter/Apocalypseshttps://gitlab.gnome.org/GNOME/librsvg/-/issues/414dominant-baseline is ignored.2024-01-20T02:04:30ZGhost Userdominant-baseline is ignored.Hi, I'm using rsvg (via the Haskell+Cairo bindings) and it seems that dominant-baseline is not taken into account. I tried with several different values and they're all being rendered the same incorrect way. Here's the SVG I'm using:
``...Hi, I'm using rsvg (via the Haskell+Cairo bindings) and it seems that dominant-baseline is not taken into account. I tried with several different values and they're all being rendered the same incorrect way. Here's the SVG I'm using:
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" height="180" width="320" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
<text dominant-baseline="hanging" font-size="60" fill="white" x="160.0" text-anchor="middle" y="90">SVG</text>
<circle fill="blue" cy="90" r="10" cx="160"/>
</svg>
```https://gitlab.gnome.org/GNOME/nautilus/-/issues/904Show warning dialog instead of hiding the star item2023-03-16T09:25:57ZCarlos SorianoShow warning dialog instead of hiding the star itemI think it's going to be useful to allow starring elsewhere, but tell the user when it cannot be done and how to fix it. (Go to control-center, add directory to tracker).
Although it's not the best solution, it could be a stopgap soluti...I think it's going to be useful to allow starring elsewhere, but tell the user when it cannot be done and how to fix it. (Go to control-center, add directory to tracker).
Although it's not the best solution, it could be a stopgap solution until Tracker has an API to track specific files. This is proposed as [gsoc project for this year](https://wiki.gnome.org/Outreach/SummerOfCode/2019/Ideas).https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/issues/100Copy process info with Ctrl+C2022-07-15T03:39:08ZGhost UserCopy process info with Ctrl+CWhen I select a line with process this this:
![image](/uploads/60d889c78a6749fb6fbafc4836fa253e/image.png)
And I press `Ctrl+C` or `Ctrl+Shift+C`, nothing is copied to the clipboard and neither there is any option on the context menu t...When I select a line with process this this:
![image](/uploads/60d889c78a6749fb6fbafc4836fa253e/image.png)
And I press `Ctrl+C` or `Ctrl+Shift+C`, nothing is copied to the clipboard and neither there is any option on the context menu to copy the information to the clipboard:
![image](/uploads/a2db312bdabbece9e13a2d427f399ef2/image.png)
I also cannot copy any information from the properties dialog:
![image](/uploads/f0ff8e75898135fe5bc960ed502a92bc/image.png)https://gitlab.gnome.org/GNOME/file-roller/-/issues/29Avoid copying extracted files to/from temporary (cache) folders when possible2023-04-15T00:56:26ZChristian StadelmannAvoid copying extracted files to/from temporary (cache) folders when possibleSteps to reproduce:
1. Have a large compressed file ("file.lzo") on a separate disk (e.g. a removable disk)
2. Open the file using file-roller
3. Extract "file" to a local folder (same filesystem as ~/.cache)
What happens:
1. File-rolle...Steps to reproduce:
1. Have a large compressed file ("file.lzo") on a separate disk (e.g. a removable disk)
2. Open the file using file-roller
3. Extract "file" to a local folder (same filesystem as ~/.cache)
What happens:
1. File-roller copies (!) the compressed file to the local disk, to `~/.cache/fr-[random]/file.lzo`
2. File-roller extracts the compressed file to the same (!) folder (`~/.cache/fr-[random]/file`
3. File-roller copies (!) the uncompressed file to the target folder on the same file system
What should happen:
1. No need to copy the source file at all. This is just wasting resources.
2. File-roller may want to extract the file to the target dir directly (why not?)
3. If you really need to do any copy operation on the local filesystem, you can just use `mv` or `g_file_move` which will use native operations (simply creating a new and deleting the old hardlink) where possible.
If you really need to do two of these operations, please do not write the intermediate file to the filesystem. You can use the concept of pipes instead. For example, to extract a .tar.lzo file, you may start two processes. The first one reads the archive and decompresses it into a pipe. The second process will untar it and write it to disk.https://gitlab.gnome.org/GNOME/gimp/-/issues/2973New (optional) UI mode: categorized (ribbon-like) toolbars2023-04-05T00:11:21ZrugkNew (optional) UI mode: categorized (ribbon-like) toolbarsOperating System: all
# Description of the feature
### Background
LibreOffice recently re-worked their toolbar UI and introduced a [ribbon-like UI](https://wiki.documentfoundation.org/ReleaseNotes/6.2#GUI) [in their latest version](ht...Operating System: all
# Description of the feature
### Background
LibreOffice recently re-worked their toolbar UI and introduced a [ribbon-like UI](https://wiki.documentfoundation.org/ReleaseNotes/6.2#GUI) [in their latest version](https://de.libreoffice.org/discover/new-features/#collapseFive).
Actually they offer different methods, i.e. one just grouping and one more-ribbon like with categories.
### Feature request
Now, obviously this is inspired by MS Office, but I really like LibreOffice adopted it. (in a nice and optional way letting users choose the UI they like) However, IMHO, it does not have to stop here. [I really think](https://social.wiuwiu.de/@rugk/101603591797031617) it makes sense for a lot more "complex" applications.
So: **introduce a ribbon-like UI in GIMP**!
# Use cases
**User Story:** As a (not-power-, but irregularly) user of this complex application, I want an easy and fast UI to quickly find features.
Reasons:
* cleaner (modern) UI
* It makes sense for new users. You don't have to search through deep menus to find a feature.
* You can (IMHO) better remember where a tool was…
* You can display slightly bigger icons, making them more “readable”
* You can display special elements in there, too, not only buttons, but actually config options
* You can display the actions suited for the currently supported tool/view/element/…
* …https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/382The applications panel show notification controls for applications not doing ...2023-12-05T21:43:34ZSébastien BacherThe applications panel show notification controls for applications not doing notificationsUsing g-c-c 3.31.90 on current Ubuntu, the applications panel seems to list every single .desktop installed on the system and show a 'notification' switch for each of those, even those not doing notifcations (gnome-calculator, yelp, ...)...Using g-c-c 3.31.90 on current Ubuntu, the applications panel seems to list every single .desktop installed on the system and show a 'notification' switch for each of those, even those not doing notifcations (gnome-calculator, yelp, ...), shouldn't that be the case only for those using X-GNOME-Autostart-Notify=true?https://gitlab.gnome.org/GNOME/dia/-/issues/40Dia doesn't comply with XDG Base Directory Specification2019-10-22T20:48:06ZIFo HancroftDia doesn't comply with XDG Base Directory SpecificationI have seen some reports on here regarding the XDG Base Directory Specification, which make me think that Dia does comply to the specification, however, the behaviour on my machine tells the exactly opposite story - that it doesn't.
On ...I have seen some reports on here regarding the XDG Base Directory Specification, which make me think that Dia does comply to the specification, however, the behaviour on my machine tells the exactly opposite story - that it doesn't.
On Fedora 29, Dia version 1:0.97.3-10 installed from the repository, along with dia-CMOS, dia-Digital, dia-electric2, dia-electronic and dia-optics, creates a directory called .dia, directly into the user's home directory, as soon as it is started for the first time on the system.https://gitlab.gnome.org/GNOME/gimp/-/issues/2985Darktable should never pop up during GIMP startup2024-03-07T20:30:42ZGrayFaceDarktable should never pop up during GIMP startupGIMP version: 2.10.8
Operating System: Win 7 64x
Package: Portable version from PortableApps.com
# Description of the bug
I've installed Darktable to import a few photos into GIMP. Now each time I start GIMP the Darktable console win...GIMP version: 2.10.8
Operating System: Win 7 64x
Package: Portable version from PortableApps.com
# Description of the bug
I've installed Darktable to import a few photos into GIMP. Now each time I start GIMP the Darktable console window pops up for a moment, which creates inconvenience and slows the startup down a bit.
# Reproduction
Always
Reproduction steps:
1. Install GIMP
2. Install Darktable with a regular installer
3. Run GIMP
…
Expected result:
No windows popping up upon startup, Darktable plugin initializing what it has to only when it's needed.
Actual result:
Darktable console window pops up for a moment, which creates inconvenience and slows the startup down a bit.https://gitlab.gnome.org/GNOME/shotwell/-/issues/108Use resumable uploads for publishing large files to Google Photos2019-02-20T19:41:50ZJens GeorgUse resumable uploads for publishing large files to Google PhotosFor files > 50Mb The Google photos API recomends to use "resumable uploads" to upload the media data:
https://developers.google.com/photos/library/guides/resumable-uploadsFor files > 50Mb The Google photos API recomends to use "resumable uploads" to upload the media data:
https://developers.google.com/photos/library/guides/resumable-uploadshttps://gitlab.gnome.org/GNOME/geary/-/issues/256Improve stored password management2023-11-24T10:42:19ZMichael GrattonImprove stored password managementLanding the new accounts editor has made the "save_password" account pref hidden - there's no UI for it any more. Also, there's no way to clear saved passwords either, aside from opening Seahorse or deleting the account. Deleting passwor...Landing the new accounts editor has made the "save_password" account pref hidden - there's no UI for it any more. Also, there's no way to clear saved passwords either, aside from opening Seahorse or deleting the account. Deleting passwords from Seahorse sucks at the moment though because the label doesn't contain the login or server name, just "Geary IMAP password", etc, in English.
I feel like all of the above is probably fine, as long we fix the label used for the secret to be translated and include more info to make it easier to find in when searching for it in Seahorse.
For save_passwords however, if its going to remain a hidden account pref, then the tickbox on the password dialog should go away.41.0https://gitlab.gnome.org/GNOME/eog/-/issues/43Should use gdk-pixbuf's stream API2023-02-09T21:56:29ZFederico Mena QuinteroShould use gdk-pixbuf's stream APIIt should be possible to convert `eog-image.c` to use gdk-pixbuf's stream API. Currently it uses `GdkPixbufLoader` by hand, which is suboptimal:
* The code has two sources of possible errors to consider - the GIO functions to read imag...It should be possible to convert `eog-image.c` to use gdk-pixbuf's stream API. Currently it uses `GdkPixbufLoader` by hand, which is suboptimal:
* The code has two sources of possible errors to consider - the GIO functions to read image data, and the `GdkPixbufLoader` functions to write data.
* Pixbuf loaders may move to natively supporting streams, instead of the old-style progressive API.
One thing I'm not completely sure about yet is how streaming would work with the current scheme of just reading the image headers to read the image size. I think EOG can just use `gdk_pixbuf_get_file_info_async` for this; the counterpart `gdk_pixbuf_get_file_info_finish` returns the image size to the caller.https://gitlab.gnome.org/GNOME/eog/-/issues/44Use the job's cancellable for the I/O APIs2019-09-09T10:18:38ZFederico Mena QuinteroUse the job's cancellable for the I/O APIs`EogJob` has a cancellable, and the loading loop in `eog-image.c` only uses it between calls to the functions in librsvg and gdk-pixbuf that actually do the work of reading the image. That code should pass the cancellable to those funct...`EogJob` has a cancellable, and the loading loop in `eog-image.c` only uses it between calls to the functions in librsvg and gdk-pixbuf that actually do the work of reading the image. That code should pass the cancellable to those functions, so they can exit early if possible.
(If everything ends up working well for this, it will mean less delays when quickly switching between images in an image collection.)https://gitlab.gnome.org/GNOME/gimp/-/issues/2995Do not use any precompression when writing .xcfxz files?2021-08-29T22:51:35ZTobias FreiDo not use any precompression when writing .xcfxz files?xcf files seem to use either RLE or zlib compression. Could it be beneficial to save them entirely uncompressed when the next step is xz compression?xcf files seem to use either RLE or zlib compression. Could it be beneficial to save them entirely uncompressed when the next step is xz compression?https://gitlab.gnome.org/GNOME/gimp/-/issues/3021B&W images have washed-out colors when zoomed out in 2.102019-02-28T13:11:00ZNokia808B&W images have washed-out colors when zoomed out in 2.10Hi dear. I have 2 versions of GIMP on my Fedora 28 X64 bit Cinnamon edition.
1st is GIMP version 2.8.22 (from my official Fedora repositories)
2nd is GIMP version 2.10.8 (as flatpak from Flathub)
I shocked when I saw a great regression ...Hi dear. I have 2 versions of GIMP on my Fedora 28 X64 bit Cinnamon edition.
1st is GIMP version 2.8.22 (from my official Fedora repositories)
2nd is GIMP version 2.10.8 (as flatpak from Flathub)
I shocked when I saw a great regression in version 2.10.8 regarding support for pcx. files !
Version 2.10.8 NEVER display 1 bit monochrome pcx. file correctly ! It displaying them as BLACK ! Only black !
Please open attached pcx. number 1. This is a 1 bit monochrome pcx. file. It is displayed correctly by version 2.8.22 but in version 2.10.8 only black !
Also, I detected that version 2.10.8 not displaying 8 bit pcx. files as precise as that in version 2.8.22 !
Please open attached pcx. number 2 & 3 in both version 2.8.22 & version 2.10.8 & look for difference. Version 2.8.22 perform much better.
[1.pcx](/uploads/3338aef3793b5bd263533c31dfa103e3/1.pcx)
[2.pcx](/uploads/f3ed3b23236e989c781ab4c8857bff93/2.pcx)
[3.pcx](/uploads/944b0e7fc2da7934cabad9e6fb891fbf/3.pcx)https://gitlab.gnome.org/GNOME/gimp/-/issues/3026Remove Advanced drop-down box for "File/New"2019-05-16T11:45:41ZElle StoneRemove Advanced drop-down box for "File/New"The Advanced drop-down box for "File/New" hides essential information. Having this essential information hidden by default means the user has to click to reveal the choices every single time they create an image, to make sure the choices...The Advanced drop-down box for "File/New" hides essential information. Having this essential information hidden by default means the user has to click to reveal the choices every single time they create an image, to make sure the choices are what's appropriate for the task at hand. It would be better to remove the Advanced drop-down box.
A person who works in the VFX industry absolutely agreed with me when I suggested to remove *all* Advanced drop-down boxes from my CCE version of GIMP. Which I did and never once missed the "convenience" (not convenient at all) of not seeing the available choices for each and every dialog without first having to click the drop-down box.
It would be nice to remove this drop-down box and allow users to actually see the available choices without having to always click to see stuff that shouldn't be hidden in the first place.
Or perhaps better yet put in Preferences the option to have *all* so-called "Advanced" options always open by default for all dialogs.
This hidden by default behavior when making a new image affects 2.10.8, 2.10 from git, and 2.99 from git.2.10