GNOME.org
 

Re: [Gimp-gui] Multi-layer selection

Hi,

On 2015-10-10 21:36, Ofnuts wrote:

On 10/10/15 18:50, Jehan wrote:



Good question. The "link" selection applies across different types of
objects
I never realized this. You can indeed link and move together layers and paths for instance. This by itself says to me these are very different concepts. 

Actually fairly useful. Transform tools on paths (especially text
paths) aren't very easy to use because their reference is the image
and not the layer from which you produced the path. But you can link
the path and a copy of the layer, and use the transform tools on the
layer, and then discard the layer and use the transformed path...
Actually a new question can be to define what is a layer link exactly! The doc says (http://docs.gimp.org/en/gimp-image-combining.html#gimp-layer-properties): "chain icon, which enables you to group layers for operations on multiple layers (for example with the Move tool or a transform tool)." 
And that's it. It does not look like a very proper definition.


As far as I can tell, it just means that a transform tool (and that
includes moves) is applied to all items linked to the one that was
used with the Transform tool. Layer groups also allow this (when you
act on the group), but only between layers.
Actually layer group can be considered a 4th concept to take into account. I would not call them "selections" though, but just various ways to interact with layers/items. Right now, you can interact on 1 layer (the active one), a group of layers, linked layers (very similar to groups except that it does not span accross item types,and also does not force sequential positioning in the item stack), and in the future maybe a selection of layers. 

I've updated the wiki page:
http://gui.gimp.org/index.php/Multi-layer_selection_workgroup
I believe we should define them properly as well as the list of actions that each concept can accept or not. The fact that this is not properly defined is likely the reason why there are so many bugs relative to various actions when performed on layer groups and linked layers. 

Jehan
For instance, when I hear operations, I think also "filters" (now even renamed GEGL *operations*). Shouldn't these be applied to all linked layers then, according to the above definition? 

This would not make sense for paint tools (because you would be
painting at the same spot on all layers....). This could make sense
(sometimes) for Color tools (by applying the same correction to all
layers). But the links are somewhat permanent, that would make them
work for everything, and since there are plenty of cases where this is
not wanted, the user would have to drop links, and then reinstate them
later... This gets messy, unless we have a "mode" to enable/disable
repeating action on linked items. Speaking of GEGL, whatever is done
here will have to be included in the GEGL nodes model.




so could be considered different (what happens to linked paths
when you just reorganize layers in the layers list? What happens when
you delete some thing in one list, should linked items of other types
be deleted too? IMHO the current "links" are a bit insufficient anyway 
because you cannot permanently link two distinct sets of items, I'd
love to have a way to tell Gimp that these two layers and this path
should always be transformed together, while these three other layers
and that other path are also always related.
It's true. In other software, like Blender, Inkscape or Scribus, you can "group" items together (not layer groups, this is independent to the stack position). Then these grouped items are considered the same item for most operations (while still retaining the ability to be ungrouped, so this is not a merge).
This said, when these items are grouped in other software, that usually mean you cannot modify them at core anymore (for GIMP, it means you can't draw into a linked layer). On these aspect, we are different, and maybe more powerful.
It very much looks like our concept of "links" except that we only allow for 1 link group at a time. And also it is not consistent since GEGL ops don't work on all items of a link group. It may indeed be worth reviewing and improving the link concept while making its definition clear. 



Repeating the action on selected items can be left to the scripts and
plug-ins, if they are provided an API to retrieve the selected items.
Yes. Actually a lot of our API calls don't do what we would expect from the equivalent graphical usage. For instance saving as XCF in the API does not clean the dirty flag (there is a separate call for this). It can be the choice (and maybe already is) to say that the API should stay as low level as possible and not automate too much, allowing more freedom to scripts. 



I'm all in favor of a rather low-level API with utility/helper
functions to make the more frequent use cases easy to code.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]