Survey: Default beabiour on clones with path operations

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Survey: Default beabiour on clones with path operations

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.


[1] https://gitlab.com/inkscape/inkscape/merge_requests/159
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Patrick Storz
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.
>
>
> [1] https://gitlab.com/inkscape/inkscape/merge_requests/159

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Patrick Storz
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...

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Maren Hachmann
In reply to this post by Patrick Storz
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.
>>
>>
>> [1] https://gitlab.com/inkscape/inkscape/merge_requests/159
>
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Jabier Arraiza
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.
> > >
> > >
> > > [1] https://gitlab.com/inkscape/inkscape/merge_requests/159
> >
> > 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!
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Jabier Arraiza
In reply to this post by Patrick Storz
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Patrick Storz
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Patrick Storz


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...

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Jabier Arraiza
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

jf barraud
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 <[hidden email]>:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Jabier Arraiza
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 <[hidden email]>:
> > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Mark Schafer
In reply to this post by jf barraud
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.




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

C R
In reply to this post by jf barraud
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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

objarni
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

jf barraud
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

clones_to_clones_of_group.inx (815 bytes) Download Attachment
clones_to_clones_of_group.py (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Jabier Arraiza
Thanks for share!

-----Original Message-----
From: JF Barraud <[hidden email]>
To: Inkscape-Devel <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> > 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@marker.
> > > 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
> > > > [hidden email]
> > > > 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
> > > [hidden email]
> > > 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
> > [hidden email]
> > 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Jabier Arraiza
In reply to this post by Patrick Storz
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 <[hidden email]>
To: [hidden email], Inkscape-Devel <[hidden email]
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...
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Survey: Default beabiour on clones with path operations

Patrick Storz
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 <[hidden email]>
> To: [hidden email], Inkscape-Devel <[hidden email]
> 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...


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel