GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2021-05-19T14:45:14Zhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/4660Import from Shotwell Photo Viewer2021-05-19T14:45:14ZBugzillaImport from Shotwell Photo Viewer## Submitted by Kip
**[Link to original bug (#755652)](https://bugzilla.gnome.org/show_bug.cgi?id=755652)**
## Description
It would be great if there was a button or menu item within Shotwell's Photo Viewer to import directly into i...## Submitted by Kip
**[Link to original bug (#755652)](https://bugzilla.gnome.org/show_bug.cgi?id=755652)**
## Description
It would be great if there was a button or menu item within Shotwell's Photo Viewer to import directly into its Photo Manager.
Version: 0.22.xhttps://gitlab.gnome.org/GNOME/pitivi/-/issues/1608Show keyframes even when moving a clip2023-07-09T16:48:07ZBugzillaShow keyframes even when moving a clip## Submitted by Jeff F.T. `@jeff`
**[Link to original bug (#3342)](https://phabricator.freedesktop.org/T3342)**
## Description
Before hidding the keyframe while moving clip (see 07c64a5d25070ed7f704760efe41135993be0b29) when select...## Submitted by Jeff F.T. `@jeff`
**[Link to original bug (#3342)](https://phabricator.freedesktop.org/T3342)**
## Description
Before hidding the keyframe while moving clip (see 07c64a5d25070ed7f704760efe41135993be0b29) when selecting a clip before trying to drag it, you were getting horrible performance out of the timeline we should fix the root of that issue.https://gitlab.gnome.org/GNOME/gimp/-/issues/762Live on-canvas preview of layer modes2022-07-31T02:27:18ZBugzillaLive on-canvas preview of layer modes## Submitted by josephbupe
**[Link to original bug (#755633)](https://bugzilla.gnome.org/show_bug.cgi?id=755633)**
## Description
Hi,
I think that there should be a live on-canvas preview of layer mode effects as one hovers through...## Submitted by josephbupe
**[Link to original bug (#755633)](https://bugzilla.gnome.org/show_bug.cgi?id=755633)**
## Description
Hi,
I think that there should be a live on-canvas preview of layer mode effects as one hovers through them before finally clicking to apply the desired layer mode.
Here is a screenshort link of what I am trying to suggest:
http://s13.postimg.org/e32bc6z4n/Gimp_Layer_Mode.gif
Best regards.
Version: git master3.2https://gitlab.gnome.org/GNOME/brasero/-/issues/291Failed to burn aac file2018-09-21T17:51:49ZBugzillaFailed to burn aac file## Submitted by jam..@..il.com
Assigned to **Brasero maintainer(s)**
**[Link to original bug (#755555)](https://bugzilla.gnome.org/show_bug.cgi?id=755555)**
## Description
I created an aac file:
ls -s pieces.aac
34624 pieces.aac...## Submitted by jam..@..il.com
Assigned to **Brasero maintainer(s)**
**[Link to original bug (#755555)](https://bugzilla.gnome.org/show_bug.cgi?id=755555)**
## Description
I created an aac file:
ls -s pieces.aac
34624 pieces.aac
$ file pieces.aac
pieces.aac: MPEG ADTS, AAC, v4 LC, 48 kHz, stereo
The file is relatively long, about 45 minutes, and plays correctly with
totem, vlc and avplay.
I would expect brasero to decode the aac file and burn it to cd
When I attempted to burn this file as an audio cd, brasero identifies it as a 6 minute audio file.
The burning proceeds without apparent error, but doesn't produce a valid audio cd.
It may be that brasero is intepreting the aac file as an uncompressed
pcm format file.
system detail:
$ lsb_release -rd
Description: Ubuntu 14.04.1 LTS
Release: 14.04
$ apt-cache policy brasero
brasero:
Installed: 3.11.3-0ubuntu1~trusty1
Candidate: 3.11.4-0ubuntu1~trusty1
Version table:
3.11.4-0ubuntu1~trusty1 0
500 http://ppa.launchpad.net/gnome3-team/gnome3-staging/ubuntu/ trusty/main amd64 Packages
*** 3.11.3-0ubuntu1~trusty1 0
100 /var/lib/dpkg/status
3.10.0-0ubuntu1 0
500 http://gb.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packageshttps://gitlab.gnome.org/GNOME/gnome-system-monitor/-/issues/58The ability to merge all of the CPU core statistics into one line graph2019-10-20T16:59:46ZBugzillaThe ability to merge all of the CPU core statistics into one line graph## Submitted by coo..@..il.com
**[Link to original bug (#755553)](https://bugzilla.gnome.org/show_bug.cgi?id=755553)**
## Description
I think that it would be really good in the gnome-system-monitor for you to be able to select an o...## Submitted by coo..@..il.com
**[Link to original bug (#755553)](https://bugzilla.gnome.org/show_bug.cgi?id=755553)**
## Description
I think that it would be really good in the gnome-system-monitor for you to be able to select an option which would mean that all of the CPU core statistics (the line graph statistics for each of the CPU cores) would merge into one line graph. This feature is already available in the Windows Task Manager and I think would be a good addition to this one.https://gitlab.gnome.org/GNOME/gimp/-/issues/761Live preview of Grow or Shrink selection on Alpha to Selection2018-05-29T22:14:42ZBugzillaLive preview of Grow or Shrink selection on Alpha to Selection## Submitted by josephbupe
**[Link to original bug (#755537)](https://bugzilla.gnome.org/show_bug.cgi?id=755537)**
## Description
Created attachment 312045
Live preview of selection editing
Hi,
It would be helpful to have live pre...## Submitted by josephbupe
**[Link to original bug (#755537)](https://bugzilla.gnome.org/show_bug.cgi?id=755537)**
## Description
Created attachment 312045
Live preview of selection editing
Hi,
It would be helpful to have live preview of active selection (matching ants) in progress. Currently, when I use the Alpha to Selection and I want to shrink or grow, I am not able to see the extent of the selection being edited until it's committed. This makes me repeat the process if I am not satisfied with the previous operation.
Please, see attached posibility for your consideration.
Best regards.
Joseph
**Attachment 312045**, "Live preview of selection editing":
![live-preview-of-selection-edit](/uploads/781c8fbefc1bba8cdbf7a97b16b1b5d9/live-preview-of-selection-edit.jpg)
Version: git masterhttps://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/143Use secure_getenv2018-02-08T12:37:46ZBugzillaUse secure_getenv## Submitted by Florian Weimer
**[Link to original bug (#755472)](https://bugzilla.gnome.org/show_bug.cgi?id=755472)**
## Description
As a safety measure against use from SUID/SGID processes, secure_getenv should be used in gireposi...## Submitted by Florian Weimer
**[Link to original bug (#755472)](https://bugzilla.gnome.org/show_bug.cgi?id=755472)**
## Description
As a safety measure against use from SUID/SGID processes, secure_getenv should be used in girepository/girepository.c to obtain the value of the GI_TYPELIB_PATH environment variable (and not g_getenv).
Alternatively, the library could refuse to work if getauxval(AT_SECURE) is true.https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/276Disc space notification - empty trash button has no confirmation or undo2019-03-20T11:28:07ZBugzillaDisc space notification - empty trash button has no confirmation or undo## Submitted by Allan Day `@aday`
**[Link to original bug (#755467)](https://bugzilla.gnome.org/show_bug.cgi?id=755467)**
## Description
When you're running out of disc space, we show a notification that contains an "Empty Trash" bu...## Submitted by Allan Day `@aday`
**[Link to original bug (#755467)](https://bugzilla.gnome.org/show_bug.cgi?id=755467)**
## Description
When you're running out of disc space, we show a notification that contains an "Empty Trash" button. If you press the button, your trash is immediately emptied, with no warning and no obvious way to undo. This is rather disconcerting and error prone - we should always help the user avoid mistakes with destructive actions.
One possible fix would be to change the label to "Empty Trash..." and, instead of emptying the trash, have it open it instead. This way, the user gets a preview of what is in the trash, and nautilus can offer undo to rectify a mistake.https://gitlab.gnome.org/GNOME/grilo/-/issues/69accept/read/write GrlMedia as json2023-12-30T01:22:38ZBugzillaaccept/read/write GrlMedia as json## Submitted by Victor Toso `@victortoso`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#755448)](https://bugzilla.gnome.org/show_bug.cgi?id=755448)**
## Description
I know we already have the serialize like "grlvideo://...## Submitted by Victor Toso `@victortoso`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#755448)](https://bugzilla.gnome.org/show_bug.cgi?id=755448)**
## Description
I know we already have the serialize like "grlvideo://grl-thetvdb/?show=CSI%20-%20Miami" but I find it rather hard to use.
So, it would be nice to accept json format for medias as well.
I've started using json format in lua-factory tests as an example.https://gitlab.gnome.org/GNOME/grilo/-/issues/68Lua-Factory tests2018-09-24T09:36:13ZBugzillaLua-Factory tests## Submitted by Victor Toso `@victortoso`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#755447)](https://bugzilla.gnome.org/show_bug.cgi?id=755447)**
## Description
We need tests to verify if sources written in lua beha...## Submitted by Victor Toso `@victortoso`
Assigned to **gri..@..e.bugs**
**[Link to original bug (#755447)](https://bugzilla.gnome.org/show_bug.cgi?id=755447)**
## Description
We need tests to verify if sources written in lua behaves as sources written in c;
We also need tests to check api for lua sources, such as grl.unzip and grl.lua.json.string_to_table() and hopefully more in the future :)
This initial patch helps verify problems with metadata-keys and it *should* check if the media is the correct one (audio, video, image, box)
It is WIP (but works already)https://gitlab.gnome.org/GNOME/gimp/-/issues/759'Open as layers' of indexed images could ask to convert the image to RGB2020-03-03T22:35:43ZBugzilla'Open as layers' of indexed images could ask to convert the image to RGB## Submitted by frank u
**[Link to original bug (#755438)](https://bugzilla.gnome.org/show_bug.cgi?id=755438)**
## Description
Created attachment 311905
rolling waves images
If i try to open images as layers some of the resulting l...## Submitted by frank u
**[Link to original bug (#755438)](https://bugzilla.gnome.org/show_bug.cgi?id=755438)**
## Description
Created attachment 311905
rolling waves images
If i try to open images as layers some of the resulting layers will represent blurred images. They look different against the original images.
Steps to reproduce:
1. Select open as layers
2. Mark all images which you want to open as layers
3. Click ok
The layers will be created but the resulting images in the layers are mostly blurred.
Expected result: The layers should be a one to one representation of the original images.
If i load each image as a single layer (mark only one image in 'open as layer', all works fine. So the bug appears only if more than one image are marked and opened as layers.
I will attach a zip file which contains the files i try to load as layers. They are part of an animation and are used to display rolling waves in the game widelands.
If related: I am using an up to date arch-linux system.
**Attachment 311905**, "rolling waves images":
[water.zip](/uploads/c80de92f4b8169572f5c3c3e66c06dc3/water.zip)
Version: 2.8.14https://gitlab.gnome.org/GNOME/gegl/-/issues/29"Extracted L" from "Tools/GEGL Operation/Extract Component/Component LAB L" i...2021-08-29T18:04:43ZBugzilla"Extracted L" from "Tools/GEGL Operation/Extract Component/Component LAB L" isn't really "L"## Submitted by Elle Stone
**[Link to original bug (#755376)](https://bugzilla.gnome.org/show_bug.cgi?id=755376)**
## Description
The "extracted L component" from GIMP "Tools/GEGL Operation/Extract Component/Component LAB L" isn't r...## Submitted by Elle Stone
**[Link to original bug (#755376)](https://bugzilla.gnome.org/show_bug.cgi?id=755376)**
## Description
The "extracted L component" from GIMP "Tools/GEGL Operation/Extract Component/Component LAB L" isn't really "L". It differs from true LAB L by the amount that the sRGB "almost perceptually uniform" TRC differs from a true perceptually uniform "LAB L" TRC (parameters below taken from http://ninedegreesbelow.com/photography/lcms-make-icc-profiles.html):
/* sRGB TRC */
cmsFloat64Number srgb_parameters[5] =
{ 2.4, 1.0 / 1.055, 0.055 / 1.055, 1.0 / 12.92, 0.04045 };
/* LAB "L" (perceptually uniform) TRC */
cmsFloat64Number labl_parameters[5] =
{ 3.0, 0.862076, 0.137924, 0.110703, 0.080002 };
It's easy to show that "Extract Component/Component LAB L" doesn't really produce LAB Lightness: Change the extracted "L component" layer's blend mode to LCH Lightness and set it over a copy of the original color layer from which the LAB L channel was extracted. If the extracted "L component" is really LAB Lightness, the image tonality won't change, but it does.
Version: git masterhttps://gitlab.gnome.org/GNOME/vte/-/issues/2228Special cursor for special modes (e.g. password entry)2024-01-23T20:33:10ZBugzillaSpecial cursor for special modes (e.g. password entry)## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#755371)](https://bugzilla.gnome.org/show_bug.cgi?id=755371)**
## Description
Mac Terminal switches the cursor to a rectangle with a circle hole inside when it's...## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#755371)](https://bugzilla.gnome.org/show_bug.cgi?id=755371)**
## Description
Mac Terminal switches the cursor to a rectangle with a circle hole inside when it's reading a password. (Screenshot: https://www.maketecheasier.com/assets/uploads/2014/11/Yosemite-Bootable-Disk-Password.jpg)
The reason I like it is because many people coming from the usual standard graphical environments get surprised and stuck why there are no dots printed after every keypress. This gives them a clue that something special's going on and it's not that the terminal became totally deaf.
With similar analogy, I think the scroll locked state or the read-only mode of the terminal could also be shown in the cursor. It has happened to me many times (even recently, after many years in the Unix world I still get tricked) that I accidentally press ^S and think that the application froze.
-----
I don't think there's a way to get notified when the termios settings change. Since it's a UI thing, we could just poll the termios with a certain FPS to always display the cursor perfectly, but that's a waste of resources.
Password: Mac Terminal.app looks for the cooked + no local echo combo. It seems to check the state after processing incoming characters, or before a UI update - not sure which. With a manual "sleep 1; stty -echo" it can be tricked into not changing the cursor when it should. But in glibc the getpass() call happens to first switch the tty settings and then print the prompt, so with a nonempty prompt it would change the cursor shape reliably.
^S/^Q: I think we should watch the input: Whenever the user presses a control character that we'd send to the tty, we can check the termios and manually figure out whether that'll block or release the output. I think this again would work quite reliably in practice.
Read-only mode: Piece of cake since we explicitly know that.
Version: git master
### Blocking
* [Bug 726176](https://bugzilla.gnome.org/show_bug.cgi?id=726176)https://gitlab.gnome.org/GNOME/gimp/-/issues/758[Document history] Enter should open document.2018-05-29T22:14:51ZBugzilla[Document history] Enter should open document.## Submitted by David Gowers
**[Link to original bug (#755323)](https://bugzilla.gnome.org/show_bug.cgi?id=755323)**
## Description
Pretty simple: when browsing through the document history dockable, the only sensible 'default actio...## Submitted by David Gowers
**[Link to original bug (#755323)](https://bugzilla.gnome.org/show_bug.cgi?id=755323)**
## Description
Pretty simple: when browsing through the document history dockable, the only sensible 'default action' IMO is to open the selected document.
However, pressing Enter seems to have no effect at all; one is currently required to doubleclick on the entry to open the document.
(The particular use case that I noticed this during, was 'use Ctrl+F to find a document by name, and then open it')
Checking some other dialogs, this situation ('there is a single obvious default action, but it is not taken when Enter is pressed; you must double-click') also seems to hold true for Named Buffers.
As well as Gradients, Brushes, and Patterns dialogs when the view type is set to Grid... Although arguably that is more excusable, since Enter does do something (rename) when the view type is set to List.
BTW, I selected 'git master' as version, but have confirmed this behaviour present in both 2.8.14 and git.
Version: git master
### See also
* [Bug 321096](https://bugzilla.gnome.org/show_bug.cgi?id=321096)https://gitlab.gnome.org/GNOME/gdm/-/issues/239gdm make install creates files that should be created at runtime2018-05-24T11:18:31ZBugzillagdm make install creates files that should be created at runtime## Submitted by Pacho Ramos `@pachoramos1`
**[Link to original bug (#755312)](https://bugzilla.gnome.org/show_bug.cgi?id=755312)**
## Description
We wonder if directories like /run/gdm, /run/gdm/greeter and var/cache/gdm should be c...## Submitted by Pacho Ramos `@pachoramos1`
**[Link to original bug (#755312)](https://bugzilla.gnome.org/show_bug.cgi?id=755312)**
## Description
We wonder if directories like /run/gdm, /run/gdm/greeter and var/cache/gdm should be created at build time. As far as we remember, this directories should be created at runtime when they are going to be used. Wouldn't be better to rely on tmpfiles.d for creating them then with the right permissions and ensure in that way that they are created properly on every boot? (when directories like /run are regenerated)
Thanks a lothttps://gitlab.gnome.org/GNOME/gimp/-/issues/757Make it possible to delete path nodes in a specific order2020-03-09T00:36:52ZBugzillaMake it possible to delete path nodes in a specific order## Submitted by Jo
**[Link to original bug (#755254)](https://bugzilla.gnome.org/show_bug.cgi?id=755254)**
## Description
sometimes i have to remove multiple path nodes, but to do so, ive to click on each node, to delete these.
Gim...## Submitted by Jo
**[Link to original bug (#755254)](https://bugzilla.gnome.org/show_bug.cgi?id=755254)**
## Description
sometimes i have to remove multiple path nodes, but to do so, ive to click on each node, to delete these.
Gimp could jump and -select to the previous created node to ease the deletiong on multiple path nodes
Version: 2.8.14https://gitlab.gnome.org/GNOME/brasero/-/issues/290The content of a .WHATEVER directory is NOT added.2021-09-18T18:05:48ZBugzillaThe content of a .WHATEVER directory is NOT added.## Submitted by hawran.diskuse
Assigned to **Brasero maintainer(s)**
**[Link to original bug (#755250)](https://bugzilla.gnome.org/show_bug.cgi?id=755250)**
## Description
Created attachment 311668
The "add" procedure, a directory...## Submitted by hawran.diskuse
Assigned to **Brasero maintainer(s)**
**[Link to original bug (#755250)](https://bugzilla.gnome.org/show_bug.cgi?id=755250)**
## Description
Created attachment 311668
The "add" procedure, a directory example.
When an .WHATEVER (a name begins with a dot) directory is added to a project to burn, the content of the directory is not added.
**Attachment 311668**, "The "add" procedure, a directory example.":
![150919-122399.dotFile-emptied.marks](/uploads/633a0f2bbf47848b05499162739c2d2f/150919-122399.dotFile-emptied.marks.png)
Version: 3.10.xhttps://gitlab.gnome.org/GNOME/gimp/-/issues/756Feature Request: drag&drop a file to the image tab in single window mode to o...2023-09-06T19:04:15ZBugzillaFeature Request: drag&drop a file to the image tab in single window mode to open it as a new image## Submitted by ala..@..il.com
**[Link to original bug (#755242)](https://bugzilla.gnome.org/show_bug.cgi?id=755242)**
## Description
Created attachment 311656
a screenshot highlighting image tab (red arrow and circle)
It makes sen...## Submitted by ala..@..il.com
**[Link to original bug (#755242)](https://bugzilla.gnome.org/show_bug.cgi?id=755242)**
## Description
Created attachment 311656
a screenshot highlighting image tab (red arrow and circle)
It makes sense for me that if you drag and drop a file to the images tab on top of your image, it would open it. That's how it works in a majority of programs.
Right now, drag and dropping to the toolbox opens it, but drag and dropping to the image tab does nothing.
Attached is a screenshot highlighting what I mean by image tab, since I'm not sure if that is what it is actually called and don't want to leave ambiguity.
**Attachment 311656**, "a screenshot highlighting image tab (red arrow and circle)":
![imagetab](/uploads/9b372b89007646b89c96f28502931798/imagetab.jpg)
Version: git masterhttps://gitlab.gnome.org/GNOME/evince/-/issues/625unable to copy images as svg2022-01-07T00:37:40ZBugzillaunable to copy images as svg## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#755221)](https://bugzilla.gnome.org/show_bug.cgi?id=755221)**
## Description
It would be excellent to be able to select a rectangle and to be able to copy the c...## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#755221)](https://bugzilla.gnome.org/show_bug.cgi?id=755221)**
## Description
It would be excellent to be able to select a rectangle and to be able to copy the content as an svg image.
Of course you can take a screenshot, but in this case your image is pixelized, you loose the vector information.
Version: 3.14.xhttps://gitlab.gnome.org/GNOME/vte/-/issues/2226Mouse/touchpad protocol enhancements2021-06-10T15:05:40ZBugzillaMouse/touchpad protocol enhancements## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#755183)](https://bugzilla.gnome.org/show_bug.cgi?id=755183)**
## Description
I'm using a touchpad all the time, and I think mouse/touchpad handling really deser...## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#755183)](https://bugzilla.gnome.org/show_bug.cgi?id=755183)**
## Description
I'm using a touchpad all the time, and I think mouse/touchpad handling really deserves the following updates. We should cooperate with Thomas and others to come up with a reasonable extension. (Unfortunately there's no public bugtracker for xterm, so I'm filing it here, lest we forget it, and perhaps for a first round of comments before we reach out to him.)
1. Smooth scroll reporting. On normal screen (when dragging the scrollbar), or on alternate screen with no mouse reporting (e.g. "less" when we convert the wheel to Up/Down keypresses) we already recognize smooth movements and send events one by one, rather than multiple of them at once after reaching 1 old unit of scrolling. This is, however, not true for apps that handle the mouse themselves, e.g. mcview. Here scrolling is rough, by 3-4 lines at a time. The mouse protocol should be extended, so that if an app requests it, we should be able to report finegrained motion.
2. Horizontal scrolling. We have vertical, why should also have horizontal just as equally. (Actually, when running "less" where we synthesize keypresses, we could already do this on our own without extending the protocol. But of course I'd also like mcview and friends to have this feature.)
3. Selective events. For some simpler apps (e.g. nano-like text editors) it might make sense to request scroll events, yet ignore clicks and let the terminal handle them the way it wants to.
4. Offscreen values. Pointed out here: http://sourceforge.net/p/joe-editor/patches/111/ an app should be able to recognize when the mouse is being dragged out of the window while its button is held down. This is so that they can handle somehow when the mouse reaches the top or bottom row (e.g. highlight the text), and handle it differently when it moves beyond (e.g. start scrolling).
Okay, the 4th one is not about touchpad, but the first three are. A decade or two ago the mouse wheel was something new and special (let alone touchpads with an easy way of scrolling), something extra compared to the two or three buttons. Nowadays, with laptops with large and good quality touchpad, and with tons of content to consume, I feel that precise scrolling with two fingers became perhaps an even more basic operation that clicking. But at the very least a first class citizen along the lines of clicking or pressing a key. We should treat it accordingly.
Version: git master