Survey: Default beabiour on clones with path operations
Hi all:
I just commit a branch [1] that convert shapes and optinaly clones to paths previously any of this path operations:
Booleans, Stroke to paths, Object to paths, Combine and Break Apart.
The cuestion is simple:
¿Whats is your prefered option about symbols? This is done in preference section and can be change by the user, but we are speaking about the default behabiour.
A: Convert to path clones and apply the operation B: Retain clones in this operatios ignoring the operation
Thank for take time to reply.
Am 15.12.2017 um 09:50 schrieb Jabier Arraiza:
Hi all:
I just commit a branch [1] that convert shapes and optinaly clones to paths previously any of this path operations:
Booleans, Stroke to paths, Object to paths, Combine and Break Apart.
The cuestion is simple:
¿Whats is your prefered option about symbols? This is done in preference section and can be change by the user, but we are speaking about the default behabiour.
A: Convert to path clones and apply the operation B: Retain clones in this operatios ignoring the operation
Thank for take time to reply.
Hi Jabier,
I'm in favor of converting to path by default. Personally if I decide to apply a path operation to a clone I don't see why it should fail on me and appreciate the automatic unlinking.
In general I assume clones are not a well known concept to start with and users will probably be confused if path operations work on some objects but not others and therefore will find it helpful if a clone is unlinked automatically. I doubt the loss of the clone will cause sorrow in typical usage scenarios.
Thanks for this change, Eduard
P.S. Just noticed some path operations do not unlink yet: - Inset / Outset - Dynamic / Linked Offset - Simplify - Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non-functional...
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non-functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non-functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non-functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
* Clone -> add path effect -> apply clone path effect. * Allow add more LPE after it * When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non-functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
On Sat, 2017-12-16 at 12:46 +0100, Eduard Braun wrote:
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non- functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Great!
Hi all,
I'm not sure it is exactly what this discussion is about, but let me suggest another point of view about clone behaviours.
In my opinion (and my practice), clones would be much easier to use if there was no difference at all between clones and masters: the user should be able to edit any clone as if it was the master, and vice versa.
Let me give more details and some reasons why I think so: Pros: 1- the distinction between clones and master is a purely technical point about where the information is stored: it has no artistic content and has no reason to interfer with the user workflow, 2- atm, if you delete the master, all the clones become free. Suppose you did it by mistake thinking it was a clone... your mistake can go unnoticed for quite a while, and there will likely be no undo then! (yes, we could also raise warnings, but they would be annoying 99% of the time). The only work arround I found to this is to systematically move all the masters to a separate dedicated layer so that they are clearly identified... It would be much simpler if, when deleting the master, one of the clones was made real and used as the new master by all the others. 3- editing clones is impossible atm; you have to edit the master. But the master is most likely not the instance you would naturally choose (because it's far away from the area you are focusing on or whatever...). Why blocking the user? Why couldn't we edit the clone as if it was the master, and apply the modification to all the relevant objects? 4- this behavior is what is used in most 3d software I think (at least in blender): objects can share data (like mesh definition wich is similar to our path "d" attribute) and you can access and edit this data from any object using it...
Cons: 1- it is not what comes first in mind when reading the svg format! Data is not really shared among objects there. However, I think it is only a matter of software behaviour and UI, so this is still 100% compatible with svg format; we could also use "symbols" for that, whose definition is slightly more symetric. 2- it is not the way it works now and most we are accustomed to think about clones as having a master... The good point is they would still have one, and you could keep your workflow. It is just a matter of adding more features to clone collections.
So my suggestion would be: - when the user tries to do anything (node-edit/add path effect/style-edit or whatever) to a clone: do it on the master, transparently to the user (if any, display the editor helpers using the clone position) - when the user tries to do something destructive (delete, ungroup, separate paths components) to an object that has clones: make one of the clones real and let the other use it as the new master, - when the user tries to do something partially destructive (apply a path effect, convert to path) to an object that has clones: do it normaly and the clones will follow.
This should of course be controllable from the user preferences panel.
Another remark that I learnt from my practice that it is generally a good idea to first put the master in a group and clone the group rather than the object itself : it is usefull when it turns out that you later decide to add more details to your master or want to change a star to a circle or whatever... Do you have the same experience? If so, we could either have an option to systematically add a group around the object we want to clone, or a menu entry to do it afterward... (I wrote a script for that years ago, maybe it's worth turning it into an official extension?).
Does this experience meet yours?
Regards, JF.
2017-12-16 12:51 GMT+01:00 Jabier Arraiza <jabier.arraiza@...2893...>:
On Sat, 2017-12-16 at 12:46 +0100, Eduard Braun wrote:
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non- functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Great!
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
To me seems very interesting, but need a big consensuous.
To me a way is that when selection is for a unique item and is a use/clone swap master:clone and reselect. Anyway need to get a plan for destructive operations on multiple elements selected having a master.
Thanks for your thoughts.
On Sun, 2017-12-17 at 23:09 +0100, jf barraud wrote:
Hi all,
I'm not sure it is exactly what this discussion is about, but let me suggest another point of view about clone behaviours.
In my opinion (and my practice), clones would be much easier to use if there was no difference at all between clones and masters: the user should be able to edit any clone as if it was the master, and vice versa.
Let me give more details and some reasons why I think so: Pros: 1- the distinction between clones and master is a purely technical point about where the information is stored: it has no artistic content and has no reason to interfer with the user workflow, 2- atm, if you delete the master, all the clones become free. Suppose you did it by mistake thinking it was a clone... your mistake can go unnoticed for quite a while, and there will likely be no undo then! (yes, we could also raise warnings, but they would be annoying 99% of the time). The only work arround I found to this is to systematically move all the masters to a separate dedicated layer so that they are clearly identified... It would be much simpler if, when deleting the master, one of the clones was made real and used as the new master by all the others. 3- editing clones is impossible atm; you have to edit the master. But the master is most likely not the instance you would naturally choose (because it's far away from the area you are focusing on or whatever...). Why blocking the user? Why couldn't we edit the clone as if it was the master, and apply the modification to all the relevant objects? 4- this behavior is what is used in most 3d software I think (at least in blender): objects can share data (like mesh definition wich is similar to our path "d" attribute) and you can access and edit this data from any object using it...
Cons: 1- it is not what comes first in mind when reading the svg format! Data is not really shared among objects there. However, I think it is only a matter of software behaviour and UI, so this is still 100% compatible with svg format; we could also use "symbols" for that, whose definition is slightly more symetric. 2- it is not the way it works now and most we are accustomed to think about clones as having a master... The good point is they would still have one, and you could keep your workflow. It is just a matter of adding more features to clone collections.
So my suggestion would be:
- when the user tries to do anything (node-edit/add path
effect/style-edit or whatever) to a clone: do it on the master, transparently to the user (if any, display the editor helpers using the clone position)
- when the user tries to do something destructive (delete, ungroup,
separate paths components) to an object that has clones: make one of the clones real and let the other use it as the new master,
- when the user tries to do something partially destructive (apply a
path effect, convert to path) to an object that has clones: do it normaly and the clones will follow.
This should of course be controllable from the user preferences panel.
Another remark that I learnt from my practice that it is generally a good idea to first put the master in a group and clone the group rather than the object itself : it is usefull when it turns out that you later decide to add more details to your master or want to change a star to a circle or whatever... Do you have the same experience? If so, we could either have an option to systematically add a group around the object we want to clone, or a menu entry to do it afterward... (I wrote a script for that years ago, maybe it's worth turning it into an official extension?).
Does this experience meet yours?
Regards, JF.
2017-12-16 12:51 GMT+01:00 Jabier Arraiza <jabier.arraiza@...2893...>:
On Sat, 2017-12-16 at 12:46 +0100, Eduard Braun wrote:
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote: > P.S. Just noticed some path operations do not unlink yet: > - Inset / Outset > - Dynamic / Linked Offset > - Simplify > - Reverse > > Should they unlink, too? I don't see a reason why not... > > > Also I can not apply a path effects to clones - is that
"by
> design"? > If > I try "Clone original" is applied automatically (without
a
> possibility > to choose another path effect) but seems to be non- > functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused
me.
Why is there a "Clone original" inserted as soon as I click "Add
path
effect"? Also after that my path is gone - that seems wrong... Maybe
just
do nothing in this case and show a warning if the user attempts
to
apply a path effect to a clone (like we did for other objects before
and
like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't
sure if
I hit a bug here or even undefined behavior...
Great!
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
FWIW - I agree as I find the current behaviour very difficult when trying to make symmetric objects using the tiled clones interface. Also the work done on bobbin lace here - https://github.com/d-bl/inkscape-bobbinlace which is getting superseded by an html variant because of this kind of difficulty.
We've discussed the in the inkscape irc channel before, and pretty much everyone agreed it would be a great solution by the end of the conversation once we figured through the potential problems. The only remaining problem being that it might be difficult to implement. For me, it's a long time wishlist item as well, so there's already a lot of consensus about it. I think anyone who uses clones as much as I do would be happy with the change (make all clones editable, and changes made to master (original) object).
Feel free to take a jab at it, Jabier. It would be a really big usability improvement for clones.
-C
On Sun, Dec 17, 2017 at 10:09 PM, jf barraud <jf.barraud@...400...> wrote:
Hi all,
I'm not sure it is exactly what this discussion is about, but let me suggest another point of view about clone behaviours.
In my opinion (and my practice), clones would be much easier to use if there was no difference at all between clones and masters: the user should be able to edit any clone as if it was the master, and vice versa.
Let me give more details and some reasons why I think so: Pros: 1- the distinction between clones and master is a purely technical point about where the information is stored: it has no artistic content and has no reason to interfer with the user workflow, 2- atm, if you delete the master, all the clones become free. Suppose you did it by mistake thinking it was a clone... your mistake can go unnoticed for quite a while, and there will likely be no undo then! (yes, we could also raise warnings, but they would be annoying 99% of the time). The only work arround I found to this is to systematically move all the masters to a separate dedicated layer so that they are clearly identified... It would be much simpler if, when deleting the master, one of the clones was made real and used as the new master by all the others. 3- editing clones is impossible atm; you have to edit the master. But the master is most likely not the instance you would naturally choose (because it's far away from the area you are focusing on or whatever...). Why blocking the user? Why couldn't we edit the clone as if it was the master, and apply the modification to all the relevant objects? 4- this behavior is what is used in most 3d software I think (at least in blender): objects can share data (like mesh definition wich is similar to our path "d" attribute) and you can access and edit this data from any object using it...
Cons: 1- it is not what comes first in mind when reading the svg format! Data is not really shared among objects there. However, I think it is only a matter of software behaviour and UI, so this is still 100% compatible with svg format; we could also use "symbols" for that, whose definition is slightly more symetric. 2- it is not the way it works now and most we are accustomed to think about clones as having a master... The good point is they would still have one, and you could keep your workflow. It is just a matter of adding more features to clone collections.
So my suggestion would be:
- when the user tries to do anything (node-edit/add path effect/style-edit
or whatever) to a clone: do it on the master, transparently to the user (if any, display the editor helpers using the clone position)
- when the user tries to do something destructive (delete, ungroup, separate
paths components) to an object that has clones: make one of the clones real and let the other use it as the new master,
- when the user tries to do something partially destructive (apply a path
effect, convert to path) to an object that has clones: do it normaly and the clones will follow.
This should of course be controllable from the user preferences panel.
Another remark that I learnt from my practice that it is generally a good idea to first put the master in a group and clone the group rather than the object itself : it is usefull when it turns out that you later decide to add more details to your master or want to change a star to a circle or whatever... Do you have the same experience? If so, we could either have an option to systematically add a group around the object we want to clone, or a menu entry to do it afterward... (I wrote a script for that years ago, maybe it's worth turning it into an official extension?).
Does this experience meet yours?
Regards, JF.
2017-12-16 12:51 GMT+01:00 Jabier Arraiza <jabier.arraiza@...2893...>:
On Sat, 2017-12-16 at 12:46 +0100, Eduard Braun wrote:
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote: > P.S. Just noticed some path operations do not unlink yet: > - Inset / Outset > - Dynamic / Linked Offset > - Simplify > - Reverse > > Should they unlink, too? I don't see a reason why not... > > > Also I can not apply a path effects to clones - is that "by > design"? > If > I try "Clone original" is applied automatically (without a > possibility > to choose another path effect) but seems to be non- > functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Great!
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
As a long time user of Inkscape, I'd love to start using clones. The reason I don't is how they work currently.
So these changes would be welcome,
/my 2 ören (Swedish "cents")
Mvh
/Olof ----------------- Är du systemutvecklare? Spana in https://cilamp.se
On 18 December 2017 at 12:03, C R <cajhne@...400...> wrote:
We've discussed the in the inkscape irc channel before, and pretty much everyone agreed it would be a great solution by the end of the conversation once we figured through the potential problems. The only remaining problem being that it might be difficult to implement. For me, it's a long time wishlist item as well, so there's already a lot of consensus about it. I think anyone who uses clones as much as I do would be happy with the change (make all clones editable, and changes made to master (original) object).
Feel free to take a jab at it, Jabier. It would be a really big usability improvement for clones.
-C
On Sun, Dec 17, 2017 at 10:09 PM, jf barraud <jf.barraud@...400...> wrote:
Hi all,
I'm not sure it is exactly what this discussion is about, but let me suggest another point of view about clone behaviours.
In my opinion (and my practice), clones would be much easier to use if there was no difference at all between clones and masters: the user should be able to edit any clone as if it was the master, and vice versa.
Let me give more details and some reasons why I think so: Pros: 1- the distinction between clones and master is a purely technical point about where the information is stored: it has no artistic content and has no reason to interfer with the user workflow, 2- atm, if you delete the master, all the clones become free. Suppose you did it by mistake thinking it was a clone... your mistake can go unnoticed for quite a while, and there will likely be no undo then! (yes, we could also raise warnings, but they would be annoying 99% of the time). The only work arround I found to this is to systematically move all the masters to a separate dedicated layer so that they are clearly identified... It would be much simpler if, when deleting the master, one of the clones was made real and used as the new master by all the others. 3- editing clones is impossible atm; you have to edit the master. But the master is most likely not the instance you would naturally choose (because it's far away from the area you are focusing on or whatever...). Why blocking the user? Why couldn't we edit the clone as if it was the master, and apply the modification to all the relevant objects? 4- this behavior is what is used in most 3d software I think (at least in blender): objects can share data (like mesh definition wich is similar to our path "d" attribute) and you can access and edit this data from any object using it...
Cons: 1- it is not what comes first in mind when reading the svg format! Data is not really shared among objects there. However, I think it is only a matter of software behaviour and UI, so this is still 100% compatible with svg format; we could also use "symbols" for that, whose definition is slightly more symetric. 2- it is not the way it works now and most we are accustomed to think about clones as having a master... The good point is they would still have one, and you could keep your workflow. It is just a matter of adding more features to clone collections.
So my suggestion would be:
- when the user tries to do anything (node-edit/add path effect/style-edit
or whatever) to a clone: do it on the master, transparently to the user (if any, display the editor helpers using the clone position)
- when the user tries to do something destructive (delete, ungroup, separate
paths components) to an object that has clones: make one of the clones real and let the other use it as the new master,
- when the user tries to do something partially destructive (apply a path
effect, convert to path) to an object that has clones: do it normaly and the clones will follow.
This should of course be controllable from the user preferences panel.
Another remark that I learnt from my practice that it is generally a good idea to first put the master in a group and clone the group rather than the object itself : it is usefull when it turns out that you later decide to add more details to your master or want to change a star to a circle or whatever... Do you have the same experience? If so, we could either have an option to systematically add a group around the object we want to clone, or a menu entry to do it afterward... (I wrote a script for that years ago, maybe it's worth turning it into an official extension?).
Does this experience meet yours?
Regards, JF.
2017-12-16 12:51 GMT+01:00 Jabier Arraiza <jabier.arraiza@...2893...>:
On Sat, 2017-12-16 at 12:46 +0100, Eduard Braun wrote:
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza: > On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote: > > P.S. Just noticed some path operations do not unlink yet: > > - Inset / Outset > > - Dynamic / Linked Offset > > - Simplify > > - Reverse > > > > Should they unlink, too? I don't see a reason why not... > > > > > > Also I can not apply a path effects to clones - is that "by > > design"? > > If > > I try "Clone original" is applied automatically (without a > > possibility > > to choose another path effect) but seems to be non- > > functional... > > I do it soon. > About path effect part, I think we need more discussion. > Realy not sure about, maybe can be another pref option by > default > to > false? > > Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Great!
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
Here is the extension I mentioned earlier: it turns all the clones of an object into clones of a group around this object...
It is usefull when you started cloning a basic object, but once you have all your clones in place, you realize that you need more details or colors and that you can only achieve it using several objects...
I don't know if there is a repository where I should drop it or if it is worth adding it to the distribution. Anyway, if it can be useful to someone, I'll be happy.
Best, JF.
Le 18/12/2017 à 13:17, Olof Bjarnason a écrit :
As a long time user of Inkscape, I'd love to start using clones. The reason I don't is how they work currently.
So these changes would be welcome,
/my 2 ören (Swedish "cents")
Mvh
/Olof
Är du systemutvecklare? Spana in https://cilamp.se
On 18 December 2017 at 12:03, C R <cajhne@...400...> wrote:
We've discussed the in the inkscape irc channel before, and pretty much everyone agreed it would be a great solution by the end of the conversation once we figured through the potential problems. The only remaining problem being that it might be difficult to implement. For me, it's a long time wishlist item as well, so there's already a lot of consensus about it. I think anyone who uses clones as much as I do would be happy with the change (make all clones editable, and changes made to master (original) object).
Feel free to take a jab at it, Jabier. It would be a really big usability improvement for clones.
-C
On Sun, Dec 17, 2017 at 10:09 PM, jf barraud <jf.barraud@...400...> wrote:
Hi all,
I'm not sure it is exactly what this discussion is about, but let me suggest another point of view about clone behaviours.
In my opinion (and my practice), clones would be much easier to use if there was no difference at all between clones and masters: the user should be able to edit any clone as if it was the master, and vice versa.
Let me give more details and some reasons why I think so: Pros: 1- the distinction between clones and master is a purely technical point about where the information is stored: it has no artistic content and has no reason to interfer with the user workflow, 2- atm, if you delete the master, all the clones become free. Suppose you did it by mistake thinking it was a clone... your mistake can go unnoticed for quite a while, and there will likely be no undo then! (yes, we could also raise warnings, but they would be annoying 99% of the time). The only work arround I found to this is to systematically move all the masters to a separate dedicated layer so that they are clearly identified... It would be much simpler if, when deleting the master, one of the clones was made real and used as the new master by all the others. 3- editing clones is impossible atm; you have to edit the master. But the master is most likely not the instance you would naturally choose (because it's far away from the area you are focusing on or whatever...). Why blocking the user? Why couldn't we edit the clone as if it was the master, and apply the modification to all the relevant objects? 4- this behavior is what is used in most 3d software I think (at least in blender): objects can share data (like mesh definition wich is similar to our path "d" attribute) and you can access and edit this data from any object using it...
Cons: 1- it is not what comes first in mind when reading the svg format! Data is not really shared among objects there. However, I think it is only a matter of software behaviour and UI, so this is still 100% compatible with svg format; we could also use "symbols" for that, whose definition is slightly more symetric. 2- it is not the way it works now and most we are accustomed to think about clones as having a master... The good point is they would still have one, and you could keep your workflow. It is just a matter of adding more features to clone collections.
So my suggestion would be:
- when the user tries to do anything (node-edit/add path effect/style-edit
or whatever) to a clone: do it on the master, transparently to the user (if any, display the editor helpers using the clone position)
- when the user tries to do something destructive (delete, ungroup, separate
paths components) to an object that has clones: make one of the clones real and let the other use it as the new master,
- when the user tries to do something partially destructive (apply a path
effect, convert to path) to an object that has clones: do it normaly and the clones will follow.
This should of course be controllable from the user preferences panel.
Another remark that I learnt from my practice that it is generally a good idea to first put the master in a group and clone the group rather than the object itself : it is usefull when it turns out that you later decide to add more details to your master or want to change a star to a circle or whatever... Do you have the same experience? If so, we could either have an option to systematically add a group around the object we want to clone, or a menu entry to do it afterward... (I wrote a script for that years ago, maybe it's worth turning it into an official extension?).
Does this experience meet yours?
Regards, JF.
2017-12-16 12:51 GMT+01:00 Jabier Arraiza <jabier.arraiza@...2893...>:
On Sat, 2017-12-16 at 12:46 +0100, Eduard Braun wrote:
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote: > Am 16.12.2017 um 11:55 schrieb Jabier Arraiza: >> On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote: >>> P.S. Just noticed some path operations do not unlink yet: >>> - Inset / Outset >>> - Dynamic / Linked Offset >>> - Simplify >>> - Reverse >>> >>> Should they unlink, too? I don't see a reason why not... >>> >>> >>> Also I can not apply a path effects to clones - is that "by >>> design"? >>> If >>> I try "Clone original" is applied automatically (without a >>> possibility >>> to choose another path effect) but seems to be non- >>> functional... >> I do it soon. >> About path effect part, I think we need more discussion. >> Realy not sure about, maybe can be another pref option by >> default >> to >> false? >> >> Thanks. > Thanks! > > Regarding path effects: > It's certainly not required but the current behavior confused me. > Why > is > there a "Clone original" inserted as soon as I click "Add path > effect"? > Also after that my path is gone - that seems wrong... Maybe just > do > nothing in this case and show a warning if the user attempts to > apply > a > path effect to a clone (like we did for other objects before and > like > we > still do if the new setting is disabled)? > > Regards, > Eduard Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Great!
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks for share!
-----Original Message----- From: JF Barraud <jf.barraud@...400...> To: Inkscape-Devel inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Survey: Default beabiour on clones with path operations Date: Tue, 19 Dec 2017 15:52:48 +0100
Hi,
Here is the extension I mentioned earlier: it turns all the clones of an object into clones of a group around this object...
It is usefull when you started cloning a basic object, but once you have all your clones in place, you realize that you need more details or colors and that you can only achieve it using several objects...
I don't know if there is a repository where I should drop it or if it is worth adding it to the distribution. Anyway, if it can be useful to someone, I'll be happy.
Best, JF.
Le 18/12/2017 à 13:17, Olof Bjarnason a écrit :
As a long time user of Inkscape, I'd love to start using clones. The reason I don't is how they work currently.
So these changes would be welcome,
/my 2 ören (Swedish "cents")
Mvh
/Olof
Är du systemutvecklare? Spana in https://cilamp.se
On 18 December 2017 at 12:03, C R <cajhne@...400...> wrote:
We've discussed the in the inkscape irc channel before, and pretty much everyone agreed it would be a great solution by the end of the conversation once we figured through the potential problems. The only remaining problem being that it might be difficult to implement. For me, it's a long time wishlist item as well, so there's already a lot of consensus about it. I think anyone who uses clones as much as I do would be happy with the change (make all clones editable, and changes made to master (original) object).
Feel free to take a jab at it, Jabier. It would be a really big usability improvement for clones.
-C
On Sun, Dec 17, 2017 at 10:09 PM, jf barraud <jf.barraud@...400...> wrote:
Hi all,
I'm not sure it is exactly what this discussion is about, but let me suggest another point of view about clone behaviours.
In my opinion (and my practice), clones would be much easier to use if there was no difference at all between clones and masters: the user should be able to edit any clone as if it was the master, and vice versa.
Let me give more details and some reasons why I think so: Pros: 1- the distinction between clones and master is a purely technical point about where the information is stored: it has no artistic content and has no reason to interfer with the user workflow, 2- atm, if you delete the master, all the clones become free. Suppose you did it by mistake thinking it was a clone... your mistake can go unnoticed for quite a while, and there will likely be no undo then! (yes, we could also raise warnings, but they would be annoying 99% of the time). The only work arround I found to this is to systematically move all the masters to a separate dedicated layer so that they are clearly identified... It would be much simpler if, when deleting the master, one of the clones was made real and used as the new master by all the others. 3- editing clones is impossible atm; you have to edit the master. But the master is most likely not the instance you would naturally choose (because it's far away from the area you are focusing on or whatever...). Why blocking the user? Why couldn't we edit the clone as if it was the master, and apply the modification to all the relevant objects? 4- this behavior is what is used in most 3d software I think (at least in blender): objects can share data (like mesh definition wich is similar to our path "d" attribute) and you can access and edit this data from any object using it...
Cons: 1- it is not what comes first in mind when reading the svg format! Data is not really shared among objects there. However, I think it is only a matter of software behaviour and UI, so this is still 100% compatible with svg format; we could also use "symbols" for that, whose definition is slightly more symetric. 2- it is not the way it works now and most we are accustomed to think about clones as having a master... The good point is they would still have one, and you could keep your workflow. It is just a matter of adding more features to clone collections.
So my suggestion would be:
- when the user tries to do anything (node-edit/add path
effect/style-edit or whatever) to a clone: do it on the master, transparently to the user (if any, display the editor helpers using the clone position)
- when the user tries to do something destructive (delete,
ungroup, separate paths components) to an object that has clones: make one of the clones real and let the other use it as the new master,
- when the user tries to do something partially destructive
(apply a path effect, convert to path) to an object that has clones: do it normaly and the clones will follow.
This should of course be controllable from the user preferences panel.
Another remark that I learnt from my practice that it is generally a good idea to first put the master in a group and clone the group rather than the object itself : it is usefull when it turns out that you later decide to add more details to your master or want to change a star to a circle or whatever... Do you have the same experience? If so, we could either have an option to systematically add a group around the object we want to clone, or a menu entry to do it afterward... (I wrote a script for that years ago, maybe it's worth turning it into an official extension?).
Does this experience meet yours?
Regards, JF.
2017-12-16 12:51 GMT+01:00 Jabier Arraiza <jabier.arraiza@...3311... es>:
On Sat, 2017-12-16 at 12:46 +0100, Eduard Braun wrote:
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote: > Am 16.12.2017 um 11:55 schrieb Jabier Arraiza: > > On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote: > > > P.S. Just noticed some path operations do not unlink > > > yet: > > > - Inset / Outset > > > - Dynamic / Linked Offset > > > - Simplify > > > - Reverse > > > > > > Should they unlink, too? I don't see a reason why > > > not... > > > > > > > > > Also I can not apply a path effects to clones - is > > > that "by > > > design"? > > > If > > > I try "Clone original" is applied automatically > > > (without a > > > possibility > > > to choose another path effect) but seems to be non- > > > functional... > > > > I do it soon. > > About path effect part, I think we need more > > discussion. > > Realy not sure about, maybe can be another pref option > > by > > default > > to > > false? > > > > Thanks. > > Thanks! > > Regarding path effects: > It's certainly not required but the current behavior > confused me. > Why > is > there a "Clone original" inserted as soon as I click "Add > path > effect"? > Also after that my path is gone - that seems wrong... > Maybe just > do > nothing in this case and show a warning if the user > attempts to > apply > a > path effect to a clone (like we did for other objects > before and > like > we > still do if the new setting is disabled)? > > Regards, > Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Great!
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--------------------------------------------------------------------- --------- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Eduard, I just make a MR. with this fix.
https://gitlab.com/inkscape/inkscape/merge_requests/166
Regards, and thanks for the inputs.
Jabier.
-----Original Message----- From: Eduard Braun <eduard.braun2@...173...> To: jabier.arraiza@...2893..., Inkscape-Devel <inkscape-devel@...1240... ceforge.net> Subject: Re: [Inkscape-devel] Survey: Default beabiour on clones with path operations Date: Sat, 16 Dec 2017 12:46:39 +0100
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non- functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Great, thanks Jabier!
Am 29.12.2017 um 13:33 schrieb Jabier Arraiza:
Hi Eduard, I just make a MR. with this fix.
https://gitlab.com/inkscape/inkscape/merge_requests/166
Regards, and thanks for the inputs.
Jabier.
-----Original Message----- From: Eduard Braun <eduard.braun2@...173...> To: jabier.arraiza@...2893..., Inkscape-Devel <inkscape-devel@...1240... ceforge.net> Subject: Re: [Inkscape-devel] Survey: Default beabiour on clones with path operations Date: Sat, 16 Dec 2017 12:46:39 +0100
Am 16.12.2017 um 12:39 schrieb Jabier Arraiza:
On Sat, 2017-12-16 at 12:10 +0100, Eduard Braun wrote:
Am 16.12.2017 um 11:55 schrieb Jabier Arraiza:
On Fri, 2017-12-15 at 22:07 +0100, Eduard Braun wrote:
P.S. Just noticed some path operations do not unlink yet:
- Inset / Outset
- Dynamic / Linked Offset
- Simplify
- Reverse
Should they unlink, too? I don't see a reason why not...
Also I can not apply a path effects to clones - is that "by design"? If I try "Clone original" is applied automatically (without a possibility to choose another path effect) but seems to be non- functional...
I do it soon. About path effect part, I think we need more discussion. Realy not sure about, maybe can be another pref option by default to false?
Thanks.
Thanks!
Regarding path effects: It's certainly not required but the current behavior confused me. Why is there a "Clone original" inserted as soon as I click "Add path effect"? Also after that my path is gone - that seems wrong... Maybe just do nothing in this case and show a warning if the user attempts to apply a path effect to a clone (like we did for other objects before and like we still do if the new setting is disabled)?
Regards, Eduard
Removing this clone path effect destroy the clone :( Realy the desirable to me work is:
- Clone -> add path effect -> apply clone path effect.
- Allow add more LPE after it
- When remove clone LPE the clone go up.
Put it on my TODO if we find consensuous.
Regards.
Ah, I see... that's how it's supposed to work! The way you describe sounds perfectly reasonable, just wasn't sure if I hit a bug here or even undefined behavior...
Am 15.12.2017 um 21:58 schrieb Eduard Braun:
Am 15.12.2017 um 09:50 schrieb Jabier Arraiza:
Hi all:
I just commit a branch [1] that convert shapes and optinaly clones to paths previously any of this path operations:
Booleans, Stroke to paths, Object to paths, Combine and Break Apart.
The cuestion is simple:
¿Whats is your prefered option about symbols? This is done in preference section and can be change by the user, but we are speaking about the default behabiour.
A: Convert to path clones and apply the operation B: Retain clones in this operatios ignoring the operation
Thank for take time to reply.
Hi Jabier,
I'm in favor of converting to path by default. Personally if I decide to apply a path operation to a clone I don't see why it should fail on me and appreciate the automatic unlinking.
In general I assume clones are not a well known concept to start with and users will probably be confused if path operations work on some objects but not others and therefore will find it helpful if a clone is unlinked automatically.
- I can confirm this is a frequently presented problem on the forums. I have a small concern that this will cause people to wonder why their clones no longer change with the original, but I suspect they will figure the reason out more easily than the other way around.
Maren
I doubt the loss of the clone will cause sorrow in typical usage scenarios.
Thanks for this change, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2017-12-15 at 23:01 +0100, Maren Hachmann wrote:
Am 15.12.2017 um 21:58 schrieb Eduard Braun:
Am 15.12.2017 um 09:50 schrieb Jabier Arraiza:
Hi all:
I just commit a branch [1] that convert shapes and optinaly clones to paths previously any of this path operations:
Booleans, Stroke to paths, Object to paths, Combine and Break Apart.
The cuestion is simple:
¿Whats is your prefered option about symbols? This is done in preference section and can be change by the user, but we are speaking about the default behabiour.
A: Convert to path clones and apply the operation B: Retain clones in this operatios ignoring the operation
Thank for take time to reply.
Hi Jabier,
I'm in favor of converting to path by default. Personally if I decide to apply a path operation to a clone I don't see why it should fail on me and appreciate the automatic unlinking.
In general I assume clones are not a well known concept to start with and users will probably be confused if path operations work on some objects but not others and therefore will find it helpful if a clone is unlinked automatically.
- I can confirm this is a frequently presented problem on the forums.
I have a small concern that this will cause people to wonder why their clones no longer change with the original, but I suspect they will figure the reason out more easily than the other way around.
Maren
I doubt the loss of the clone will cause sorrow in typical usage scenarios.
Thanks for this change, Eduard
Thanks so much Maren and Eduard for the feedback!
participants (8)
-
C R -
Eduard Braun -
Jabier Arraiza -
jf barraud -
JF Barraud
-
Maren Hachmann -
Mark Schafer -
Olof Bjarnason