Once I was used to the behaviour I found it quite useful. If I need to delete a number of consecutive layers, I select the top or bottom one then use the down or up arrow to walk through the layers I want deleted then click the delete button repeatedly.

However, even knowing it and leveraging it, I still get caught when I move from one layer to another far away in the stack to delete then find the active layer is way back in the stack.

Regarding the comments in the bug report, I can think of at least one time deleting a layer currently leaves no layer selected...when there is only one layer. Not near my machine to check what happens if you select a channel as a drawable then select a layer and delete it. Does it set the channel active?

-Rob A>

On 3/4/10, Luiz Felipe Moraes Pereira wrote:

Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758

I was advised to present this idea here, what do you think?

Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem.

Luiz Felipe Moraes Pereira writes:

Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem.

This used to annoy me a lot, because I frequently want to delete, say, the top 5 layers. But once I figured out what it was doing, I developed a habit of clicking on the layers I want to delete in sequence before deleting. For instance, click on the 5th layer from the top, then the 4th, and so on until I get to the top; then click Delete 5 times. It sounds tedious but it doesn't take long at all -- certainly it's a lot faster than scrolling back up each time. Try it -- you may find that it solves the problem.

...Akkana

On Fri, Mar 5, 2010 at 3:05 PM, Akkana Peck wrote:

Luiz Felipe Moraes Pereira writes:

Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem.

This used to annoy me a lot, because I frequently want to delete, say, the top 5 layers. But once I figured out what it was doing, I developed a habit of clicking on the layers I want to delete in sequence before deleting. For instance, click on the 5th layer from the top, then the 4th, and so on until I get to the top; then click Delete 5 times. It sounds tedious but it doesn't take long at all -- certainly it's a lot faster than scrolling back up each time. Try it -- you may find that it solves the problem.

yes, I do that as well.

The new Layer Groups feature in 2.7 will ease this and several other workflows a whole lot.
(For example, probably all the layers you are deleting, if more than one, would not be themselves part of the same group - you just have to delete the group)

js
->

       ...Akkana

On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote:

Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758

I was advised to present this idea here, what do you think?

Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem.

To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer.

/ Martin

I've always hated the way that worked, I've got a script that deletes the active layer, then sets the layer underneath it to active if anyone wants to use it...

#!/usr/bin/env python # -*- coding: utf-8 -*-
#
# delete-layer.py - Version 1.0
# Copyright (C) 07/11/2008 by Jerry Baker # www.gimpthoughts.com
#
# Deletes active layer then selects the layer underneath. #
# This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. #
# This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. #
# You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

# --- Imports from gimpfu import *

gettext.install("gimp20-python", gimp.locale_directory, unicode=True)

def delete_layer(image, drawable): image.undo_group_start()

layer_index = image.layers.index(image.active_layer) if layer_index == (len(image.layers)-1): layer_index -= 1
image.remove_layer(image.active_layer) if layer_index >= 0:
image.active_layer = image.layers[layer_index]

image.undo_group_end()

register( "delete-layer",
N_("Deletes active layer then selects the layer underneath."), "Deletes active layer then selects the layer underneath.", "Jerry Baker",
"Jerry Baker",
"07/11/2008",
N_("Delete Active Layer"),
"RGB*, GRAY*, INDEXED*",
[
# --- Parameters
(PF_IMAGE, "image", _("Image"), None), (PF_DRAWABLE, "layer", _("Drawable"), None), ],
[
# --- Results
],
delete_layer,
menu="/_Layer",
domain=("gimp20-python", gimp.locale_directory) )

main()

On 03/05/2010 02:22 PM, Martin Nordholts wrote:

On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote:

Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758

I was advised to present this idea here, what do you think?

Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem.

To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer.

/ Martin

I've verified the behaviour is inconsistent, at least which could be considered a bug. I assumed it would go to the last drawable, but that isn't so...

Deleting a channel always makes the channel that was below it active (regardless of the active order before), unless it is the last channel, in which case the last layer that was selected becomes active.

-Rob A>

On Fri, 2010-03-05 at 20:22 +0100, Martin Nordholts wrote:

On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote:

Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758

I was advised to present this idea here, what do you think?

Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem.

To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer.

Perhaps the problem is just the scrolling then. GIMP could continue to select the previously selected layer, but it wouldn't have to scroll that layer into sight. It could instead just leave the list-view as it is.

Sven

On Saturday 06 March 2010 14:56:21 Sven Neumann wrote:

To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer.

Perhaps the problem is just the scrolling then. GIMP could continue to select the previously selected layer, but it wouldn't have to scroll that layer into sight. It could instead just leave the list-view as it is.

Please no. Only thing worse than selecting random(for those of us that do not remember wha layer it was that they clicked at last) item and scrolling to it is selecting the random item and not making it apparent that this was done.

--Alexia

On Sat, 2010-03-06 at 13:56 +0100, Sven Neumann wrote:

On Fri, 2010-03-05 at 20:22 +0100, Martin Nordholts wrote:

On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote:

Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758

I was advised to present this idea here, what do you think?

Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem.

To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer.

Perhaps the problem is just the scrolling then. GIMP could continue to select the previously selected layer, but it wouldn't have to scroll that layer into sight. It could instead just leave the list-view as it is.

Nope, the problem here is that we are using a mechanism that is actually meant for selecting a layer once you deleted the last channel. The MRU list of layers doesn't really make sense to use when we are dealing with layers only, since the obviously expected behavior when deleting a list/tree element is to select a neighboring element. Everybody please calm down, I plan to change things here anyway, the refactoring of the image's item trees is not over yet.

stay tuned, --mitch