After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760763 - Dropping multiple images on canvas is not consistent.
Dropping multiple images on canvas is not consistent.
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2016-01-17 23:28 UTC by Jehan
Modified: 2017-11-15 19:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (2.62 KB, patch)
2017-11-15 19:57 UTC, Jehan
none Details | Review

Description Jehan 2016-01-17 23:28:38 UTC
Currently dropping multiple image on the canvas has the following behaviors:

- If an image is already opened, open all dropped images as layers of the opened image.
- If the canvas is empty, open all dropped images as separate new GIMP images.

This is not consistent. I would expect that when the canvas is empty, all dropped image would open as layers of a new image (based on the first of the list of dropped image), especially since the current behavior is also possible by dropping on the toolbox instead (so there is no loss of feature).

Of course, since the "drop on the toolbox" feature is so hardly discoverable, this should probably not be changed until bug 759814 were to be implemented.
Comment 1 Michael Schumacher 2016-05-25 12:53:15 UTC
Can the user be reasonably sure about what the "first" image is?
Comment 2 Jehan 2016-05-25 13:14:45 UTC
You mean the first when you drop several images at the same time? That's a good question. My tests (no code verification), when dropping from Nautilus/GNOME Files, show me that GIMP seems to use whatever order the user selected in Nautilus (Name, Last Modified, etc.), which seems a pretty good thing to me, because it means that you get what you see (if file A is before file B in Nautilus, then it will be below as well in GIMP after dropping).

In any case, if we considered this to be a problem, that's already an existing problem and is not really relevant to this bug report. This could be a separate bug report if needed.
But personally I consider the current state (not reordering, just using whatever order you get) is probably the best bet.
Comment 3 Michael Schumacher 2016-05-25 15:33:31 UTC
My point was that a totally unexpected image might end up as the initial (and background) layer and determine the image size, mode and other stuff (e.g. metadata).

The ordering itself is another issue and happens for the drop on an existing image window, too.
Comment 4 Jehan 2017-11-15 19:57:18 UTC
Created attachment 363753 [details] [review]
Patch

Ok so I had a patch for this, but discussing with Aryeom, we decided that this was likely not the best idea. The concept is not "dropping on toolbox vs dropping on display" but "dropping on an existing image or not". So when the shell is empty, we don't drop on an existing image so that's ok that it behaves as toolbox dropping in such a case.

I still had a patch so I just upload it for storage/memory in case the decision ever changed, but I won't push it and will consider this report as NOTABUG.