Skip to content

app: images dockable: delete button is not disabled when image has display

Environment/Versions

  • GIMP version: latest
  • Package: self-built

Symptoms

In the Images dockable, the "Delete" button should be disabled when the selected image has a display, but it is not, under certain conditions.

Reference: the user manual says "Delete ... This command works only on an image which is loaded without any window."

Replicate

In single-window mode.

Open the Images dockable: Windows>Dockable Dialogs>Images

Case 1

  1. Create an image that has no display: open the ScriptFu Console and enter "(gimp-image-new 64 64 RGB)".

Expect "[Untitled]-1" to appear as a row in the Images dockable.

Expect the buttons at the bottom of the Images dockable to be disabled (gray.)

  1. Select that row by clicking on it.

Expect the buttons at the bottom of the Images dockable to be enabled.

  1. Open a display for the image by clicking on the "Create a new display for this image" button at the bottom.

Expect a display window to open, showing the image (all transparent.)

Expect a thumbnail for the image to appear in the bar of image tabs.

Expect the "Delete this image" button to be disabled (gray)

Actual result: the "Delete this image" button is NOT disabled.

(If you click on the button, the image disappears from the Images dockable but NOT from the tab bar of images. And so forth, it can lead to strange behavior.)

Case 2

  1. New an image: File>New then OK.

Expect "[Untitled]-1" to appear as thumbnail tab, and image in the canvas.

Expect "[Untitled]-1" row to appear in the Image dockable. Expect the row to be highlighted.

Expect the buttons at the bottom of the Images dockable to be disabled (gray.) (Since the image has a display, you should not be able to "Delete" it from the Images dockable.)

Actual: the "Delete" button is NOT disabled

  1. Click the "Delete" button at the bottom of the Images dockable.

Expect the row to disappear from the Images dockable.

Expect the tab to close and the canvas to be empty.

Actual: the tab does not disappear and the image remains in the canvas.

Discussion

The "Images" dockable and the tab bar of images (in single window mode) are two widgets showing thumbnails of sets of images. Their behavior is not the same.

The "Images" dockable shows all open images, even those without displays, i.e. without a thumbnail in the tab bar of images, or a separate canvas window. Thus the "Images" dockable shows a larger set of images, specifically, more images opened by plugins or from an interpreter console.

Both widgets have X buttons whose purpose is to close/delete the image. But you can only close (sic "Delete") an image that has no display from the Images dockable. Also, from the Images dockable, you should only be able to Delete an image that does have a display, i.e. that does not appear in the tab bar of images.

Also, I think the UI could be changed. Why shouldn't you be able to close an image that has a display from either widget? Also, in the first case, if you close the image from the tab bar, the image remains in the Images dockable, which seems strange, and is not the same behavior as for an image newed/opened normally.

Importance

The first case is rare. Most users won't encounter it.

The second case is somewhat common. Many users will create a new image, but few will delete it from the Images dockable.

Nothing seems to crash, it seems to be just GUI weirdness.

Related

#9285

Diagnosis

I somewhat followed the call chain.

image_new_create_image()
  gimp_image_new_from_template()

      gimp_image_view_select_item
         gimp_ui_manager_update
            images_actions_update
                This should disable the delete button,
                when the image has a display
                but at this point, it doesn't have a display.
  gimp_create_display

      There are more calls to gimp_ui_manager_update here
      but apparently not to update the images actions

So my hypothesis is that creation of a display for an image should signal(?) somewhere to invoke images_actions_update again.