Re: [Gimp-gui] Multi-layer selection
Hi, On 2015-10-13 19:47, Ofnuts wrote: On 12/10/15 15:20, Jehan wrote: 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. Layers groups are first an foremost the equivalent of parentheses for compositing operations (ie, all compositing is done within the group, then the group is composited with its siblings). You could want to rotate a layer across several groups. By the way, let's not forget layer masks. They would often be selected with their layer, but separate selection will also have its uses. Do you have a wiki account by the way? I feel you give enough feedback to add these directly on the wiki too. :-) You can ask an account to ankh on IRC (Liam on this mailing list). I also feel that our work could also to improving documentation at some point as well, when we will have managed to define every concepts and clearly say what are the differences. Jehan
Re: [Gimp-gui] Multi-layer selection
On 12/10/15 15:20, Jehan wrote: 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. Layers groups are first an foremost the equivalent of parentheses for compositing operations (ie, all compositing is done within the group, then the group is composited with its siblings). You could want to rotate a layer across several groups. By the way, let's not forget layer masks. They would often be selected with their layer, but separate selection will also have its uses.
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.
Re: [Gimp-gui] Multi-layer selection
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. 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.
Re: [Gimp-gui] Multi-layer selection
Hi, On 2015-10-10 18:24, Ofnuts wrote: On 10/10/15 15:58, Jehan wrote: Hi, 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 way). * selection for geometric transform (actually faked as 'links') (even if links also apply to non-layer things, such as paths and channels) * selection for operations/management (drag/drop in the Layers list, possibly drag/drop to another image, set visibility, mode, opacity, alpha/pixel lock, links, add alpha channel... , remove text information, text-to-path...) 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 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 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. 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 selected? 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. Jehan 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. Jehan
Re: [Gimp-gui] Multi-layer selection
On 10/10/15 15:58, Jehan wrote: Hi, 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 way). * selection for geometric transform (actually faked as 'links') (even if links also apply to non-layer things, such as paths and channels) * selection for operations/management (drag/drop in the Layers list, possibly drag/drop to another image, set visibility, mode, opacity, alpha/pixel lock, links, add alpha channel... , remove text information, text-to-path...) 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 objects 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. 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 selected? 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. 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. Jehan
Re: [Gimp-gui] Multi-layer selection
Hi, 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. * selection for geometric transform (actually faked as 'links') (even if links also apply to non-layer things, such as paths and channels) * selection for operations/management (drag/drop in the Layers list, possibly drag/drop to another image, set visibility, mode, opacity, alpha/pixel lock, links, add alpha channel... , remove text information, text-to-path...) So a question can be: is this a problem? Is it meaningful for these concepts to be separated? 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 selected? 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. 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. Jehan
Re: [Gimp-gui] Multi-layer selection
Hi, On 2015-10-09 23:17, Ofnuts wrote: On 09/10/15 23:15, Ofnuts wrote: PS: should not the mail from this list have a properly tagged subject line [Gimp-gui-list] like its two siblings? Actually the tag should be [Gimp-gui] Done (I think. Let's see with this email!). I guess these prefixes were made long ago. Now we say that GIMP should be all-caps. Shouldn't this be [GIMP-gui] then? Jehan ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: Multi-layer selection
On 09/10/15 23:15, Ofnuts wrote: PS: should not the mail from this list have a properly tagged subject line [Gimp-gui-list] like its two siblings? Actually the tag should be [Gimp-gui]
Re: Multi-layer selection
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) * selection for geometric transform (actually faked as 'links') (even if links also apply to non-layer things, such as paths and channels) * selection for operations/management (drag/drop in the Layers list, possibly drag/drop to another image, set visibility, mode, opacity, alpha/pixel lock, links, add alpha channel... , remove text information, text-to-path...) 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. PS: should not the mail from this list have a properly tagged subject line [Gimp-gui-list] like its two siblings?
Re: Multi-layer selection
Hi, On 2015-10-09 17:50, Jehan wrote: Hi, On 2015-10-09 15:48, Pat David wrote: I'd agree that the wiki is possibly the best place to flesh these ideas out with history and more flexibility to utilize images and media to demonstrate our ideas (a big + when dealing with some of the concepts I'm sure will come to light). On Fri, Oct 9, 2015 at 7:57 AM Jehan wrote: This said, I want to prepare a procedure to how we will work in the wiki before giving out too many accounts. Well, we are not so many at the moment, so it may not be so bad to get everyone interested a wiki account. Should we have a page per concept/idea, and a tag to organize on an index page of some sort to show what has been proposed and where the ideas may be in terms of viability? What about this: http://gui.gimp.org/index.php/Procedure_for_Specifications ? Basically if a topic is worth working on, we create a "workgroup" page. For instance, for the multi-layer selection, we could edit http://gui.gimp.org/index.php/Multi-layer_selection_workgroup Well I've created the said page: http://gui.gimp.org/index.php/Multi-layer_selection_workgroup Anyone, feel free to update the wiki page. Jehan Once we decide it is time to start the spec, we will create a separate page. What is important is to include the wiki pages into the right MediaWiki categories. I have also created a (crappy) template which should allow us to track spec status and inclusion in GIMP (when we will have many). This is only a first very basic skeleton of procedure to kickstart the process. I am expecting this to evolve. :-) Jehan ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: Multi-layer selection
Hi, On 2015-10-09 15:48, Pat David wrote: I'd agree that the wiki is possibly the best place to flesh these ideas out with history and more flexibility to utilize images and media to demonstrate our ideas (a big + when dealing with some of the concepts I'm sure will come to light). On Fri, Oct 9, 2015 at 7:57 AM Jehan wrote: This said, I want to prepare a procedure to how we will work in the wiki before giving out too many accounts. Well, we are not so many at the moment, so it may not be so bad to get everyone interested a wiki account. Should we have a page per concept/idea, and a tag to organize on an index page of some sort to show what has been proposed and where the ideas may be in terms of viability? What about this: http://gui.gimp.org/index.php/Procedure_for_Specifications ? Basically if a topic is worth working on, we create a "workgroup" page. For instance, for the multi-layer selection, we could edit http://gui.gimp.org/index.php/Multi-layer_selection_workgroup Once we decide it is time to start the spec, we will create a separate page. What is important is to include the wiki pages into the right MediaWiki categories. I have also created a (crappy) template which should allow us to track spec status and inclusion in GIMP (when we will have many). This is only a first very basic skeleton of procedure to kickstart the process. I am expecting this to evolve. :-) Jehan
Re: Multi-layer selection
I'd agree that the wiki is possibly the best place to flesh these ideas out with history and more flexibility to utilize images and media to demonstrate our ideas (a big + when dealing with some of the concepts I'm sure will come to light). On Fri, Oct 9, 2015 at 7:57 AM Jehan wrote: > > This said, I want to prepare a procedure to how we will work in the wiki > before giving out too many accounts. > > Well, we are not so many at the moment, so it may not be so bad to get everyone interested a wiki account. Should we have a page per concept/idea, and a tag to organize on an index page of some sort to show what has been proposed and where the ideas may be in terms of viability?
Re: Multi-layer selection
Hi, On 2015-10-09 14:51, Alexandre Prokoudine wrote: On Fri, Oct 9, 2015 at 3:44 PM, Jehan wrote: Right now, you cannot multi-select layers. The feature request: https://bugzilla.gnome.org/show_bug.cgi?id=730216 Multi layer selection's main advantage would be to move several layers at once, which happens when you work with dozens of layers, then suddenly realize you need to organize your layers under layer groups. Right now you can only move them one at a times, which is tedious. You'd expect to be able to shift and ctrl-click layers (in a similar fashion as in a file browser). I'd suggest writing down somewhere all the things we could do with multiple layers selection (like locking from transformation and/or painting, or maybe adding alpha channels to multiple layers). Having a more ore less complete list of use cases would help. The wiki at gui.gimp.org could be just the place for that. This is the plan. As you can see, I have already started to modify the wiki (well only the presentation in first page right now, but more is planned!). We have given accounts to a few people already. If you ask ankh, he has an admin account and can make you an account. This said, I want to prepare a procedure to how we will work in the wiki before giving out too many accounts. Jehan Alex ___ gimp-gui-list mailing list gimp-gui-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-gui-list
Re: Multi-layer selection
On Fri, Oct 9, 2015 at 3:44 PM, Jehan wrote: > Right now, you cannot multi-select layers. > The feature request: https://bugzilla.gnome.org/show_bug.cgi?id=730216 > > Multi layer selection's main advantage would be to move several layers at > once, which happens when you work with dozens of layers, then suddenly > realize you need to organize your layers under layer groups. Right now you > can only move them one at a times, which is tedious. You'd expect to be able > to shift and ctrl-click layers (in a similar fashion as in a file browser). I'd suggest writing down somewhere all the things we could do with multiple layers selection (like locking from transformation and/or painting, or maybe adding alpha channels to multiple layers). Having a more ore less complete list of use cases would help. The wiki at gui.gimp.org could be just the place for that. Alex
Multi-layer selection
Hello all, Let's kickstart this mailing list with a discussion about an absence of feature that has annoyed Aryeom for very long. So I know she will enjoy participate to this one. :-) Right now, you cannot multi-select layers. The feature request: https://bugzilla.gnome.org/show_bug.cgi?id=730216 Multi layer selection's main advantage would be to move several layers at once, which happens when you work with dozens of layers, then suddenly realize you need to organize your layers under layer groups. Right now you can only move them one at a times, which is tedious. You'd expect to be able to shift and ctrl-click layers (in a similar fashion as in a file browser). There has been a new feature request recently about having linked layers play such role, so that moving several link layers move them all together: https://bugzilla.gnome.org/show_bug.cgi?id=755972 This makes sense too. I am not sure if this is as discoverable as the concept of "selection", which most users know from using it in every software (and advanced users would expect a few behavior patterns, like shift-click = select all items between current selection and click; or ctrl-click = on/of selection on clicked item while keeping existing selection, etc.). Hence many people would try to multi-select intuitively and discover it does not work. 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? And so on, many questions to be answered which could end up in a specification to allow new behaviors. :-) Thanks! Jehan
