On 2015-10-10 18:24, Ofnuts wrote:
On 10/10/15 15:58, Jehan wrote:
On 2015-10-09 23:15, Ofnuts wrote:
On 09/10/15 14:44, Jehan wrote:
So should we have these 2 concepts?
If we have multi-selection, do you have a concept of "main selected
layer", which is the one where drawing occurs? Is it then the first
of the last selected layer?
Actually you end up with three selection concepts:
* selection for painting (single selection)
Right, this can be considered as a different selection concept. This
said, it seems nobody really want to disrupt the idea that painting
can only occur for a single layer at a time.
Yes, that's why in the end we have three selection types/concepts. We
have to keep that one (that also applies to copy/paste ops, by the
* selection for geometric transform (actually faked as 'links')
(even if links also apply to non-layer things, such as paths and
* selection for operations/management (drag/drop in the Layers
possibly drag/drop to another image, set visibility, mode, opacity,
alpha/pixel lock, links, add alpha channel... , remove text
So a question can be: is this a problem? Is it meaningful for these
concepts to be separated?
Good question. The "link" selection applies across different types of
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
Actually a new question can be to define what is a layer link exactly!
The doc says
"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.
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?
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.
In addition to this you have to consider how scripts can use this.
Most currently trigger on the link or visible flags so having a third
flag could be good.
Of course, everything will have to be considered, API included. The
spec will have to be as exhaustive as possible and handle every case
of layer modification: what should happen when several layers are
Even when keeping different selection/link concepts, it may also be
the chance to write down the spec for linked layers too, and clarify
how API should behave with linked layers, by the way.
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.
Since I think that these changes won't be for GIMP 2.10, then probably
for GIMP 3.0 instead, API changes may occur, if not mistaken.