Timothée Giet | 10 May 13:44 2012
Picon

Hi Synfig devs

Hi!

This is my first post on the synfig dev mailing list.
To introduce me quickly, I'm Timothée Giet aka Animtim (and aka Satrip on synfig forum and some other places)
French graphic artist, loving free software and free culture…

So first topic, we discussed with Zelgadis at LGM about fixing the terminology used in Synfig, as in some place we could use more specific terms, that could fit better, be less confusing, and so enhance the synfig experience.
So first I'd like to know if everybody would be ok for such change.

Then we would need to agree on a list of the terms to change, and on the new terms to use.

So as Zelgadis told me he already have a sort of list of names to propose, so he can start by sending it here, then if others have suggestions to complete or modify, just say it.


Then only at the end when everyone is ok with the final list, we can start the huge task to rename everything in the code/translations/doc.
This is another part of the problem, but we'll see then.

Nice to be on this list, I hope we can get some good work done together :)

Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Carlos Lopez Gonzalez | 10 May 20:45 2012
Picon
Picon

Re: Hi Synfig devs

Hi Timothée! welcome aboard!

The change proposed is not only agreed by me but also needed. I don't have a whole idea of which terms are wrong or need change but I do agree that terminology is the basis of a good development, code, learning and support of Synfig.
First I would start establishing the first requisite: English is the official language for all the Synfig code, documentation and any material related to language. I'm not expert on it but I do prefer American English over British English (color instead colour). It can be discussed which flavor of English is preferred.

Also I would like to mention that do a global change on the code is not a big deal with the modern edition tools and search and replace all the occurrences of one string is not so difficult. Other thing is that there were variations of the same word (shortened for example) and we want to replace by other. This might be done manually. I don't know about wiki and its complexity on changing strings.

Finally I would like to know if this terminology fixing will cover the code variable names too. It can be done but it is an internal thing that wouldn't affect others than coders. I personally would prefer to take time documenting the code instead of change the name of a variable or class. Also change the code terminology implies to understand it first, which is a requisite to have it well documented too.

Waiting for the first list of terms.
Cheers!
De: Timothée Giet <animtim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Para: synfig-devl-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Enviado: Jueves 10 de Mayo de 2012 13:44
Asunto: [Synfig-devl] Hi Synfig devs

Hi!

This is my first post on the synfig dev mailing list.
To introduce me quickly, I'm Timothée Giet aka Animtim (and aka Satrip on synfig forum and some other places)
French graphic artist, loving free software and free culture…

So first topic, we discussed with Zelgadis at LGM about fixing the terminology used in Synfig, as in some place we could use more specific terms, that could fit better, be less confusing, and so enhance the synfig experience.
So first I'd like to know if everybody would be ok for such change.

Then we would need to agree on a list of the terms to change, and on the new terms to use.

So as Zelgadis told me he already have a sort of list of names to propose, so he can start by sending it here, then if others have suggestions to complete or modify, just say it.


Then only at the end when everyone is ok with the final list, we can start the huge task to rename everything in the code/translations/doc.
This is another part of the problem, but we'll see then.

Nice to be on this list, I hope we can get some good work done together :)

Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/synfig-devl


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Zelgadis | 11 May 09:45 2012
Picon

Re: Hi Synfig devs

> De: Timothée Giet <animtim@...>

> So first topic, we discussed with Zelgadis at LGM about fixing the
> terminology used in Synfig, as in some place we could use more specific
> terms, that could fit better, be less confusing, and so enhance the synfig
> experience.
> So first I'd like to know if everybody would be ok for such change.
>
> Then we would need to agree on a list of the terms to change, and on the new
> terms to use.
>
> So as Zelgadis told me he already have a sort of list of names to propose,
> so he can start by sending it here, then if others have suggestions to
> complete or modify, just say it.

Hi, Timothée!
Here's my list:
* Duck -> Control point
* Curves Panel -> Trajectories Panel (or Graphs Panel ?)
* BLine -> Curve
* Groups -> Sets
* Encapsulate -> Group

I think those ones are already enough.

Also we have "Paste Canvas" - "Inline Canvas" - "Exported Canvas"
thing that is a little bit confusing for users.

> Then only at the end when everyone is ok with the final list, we can start
> the huge task to rename everything in the code/translations/doc.
> This is another part of the problem, but we'll see then.

2012/5/11 Carlos Lopez Gonzalez <carloslopezgonzalez@...>:
> Also I would like to mention that do a global change on the code is not a
> big deal with the modern edition tools and search and replace all the
> occurrences of one string is not so difficult. Other thing is that there
> were variations of the same word (shortened for example) and we want to
> replace by other. This might be done manually. I don't know about wiki and
> its complexity on changing strings.

For wiki we can do global search and replace, but I'm not sure if it
will work everywhere. We need to be careful with that and of course
the work with proofreading all stuff is still required.

> Finally I would like to know if this terminology fixing will cover the code
> variable names too. It can be done but it is an internal thing that wouldn't
> affect others than coders. I personally would prefer to take time
> documenting the code instead of change the name of a variable or class. Also
> change the code terminology implies to understand it first, which is a
> requisite to have it well documented too.

My suggestion is to go with the same way as we did for Zoom/Scale
layer -> leave variables untouched. At least for now.

Cheers!
K.

--

-- 
http://morevnaproject.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Timothée Giet | 11 May 15:22 2012
Picon

Re: Hi Synfig devs

Cool, I'm glad you agree with this Genete.
About the variables names, I don't have much to say as I don't really code myself, so it's up to you to decide if it's needed.

Thanks for the list Zelgadis, here is my opinion:

-Duck → Control point = OK (Although the name of Ducks will probably stay in my mind a long time now… was kinda funny :D )
-Curves Panel → I propose "Parameter-Animation-Curves", or just "Parameter Curves" (I thought about having a name like IPO curves in blender as it looks similar, although for now in synfig it's only a visual representation,(right?!) no control/handles on it directly, so is not an "IPO", but still a curve). Parameter Graph would be fine too.
-Bline → I propose "Path" , more precise than Curve in our context as it can be used to draw different kinds of Paths, and is also better to replace in "Create Curve gradient Bline" for example ;) .
-Groups → Sets OK (I agree as its a special way to group items, different from the common understanding of layer groups in other softs or like we have we have in encapsulating, so better to use another word; and "Sets" does fit the pupose to make some sets of layer types).
-Encapsulate → Group half OK, though I did like the capsule analogy… it illustrates well to me the fact that each capsule isolates its content from the rest, more than the generic "group" word.
So if some else want to keep the encapsulate terminology (and maybe then we can use the term "capsule" for the group, as represented by its icon)…
But if everyone wants to go for "To Group" in "Groups", then I'm fine with it.

Waiting your comments
Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Carlos Lopez Gonzalez | 13 May 09:06 2012
Picon
Picon

Re: Hi Synfig devs

Hi!
here are my thoughts:
Duck: this name caused troubles from the first day and it should be fit in some way. Control point is ok. Perhaps for BLines's vertices it is perfect but for other kind of parameters it is not full perfect. What about "Handle"?. It is just a suggestion because I like Control point.
Curves panel: I'm unsure about this. Graphs panel is the most liked by me.
BLine: I prefer Curve. The "Create curve gradient BLine" is wrong. It should be "Create curved Gradient Layer". There are some mistakes on the English version of the BLine tool. But on the other hand "Path tool" sounds better than "Curve tool" :-/
Groups & Encapsulate: I like both like they are now. I think that the problem is that all that slang of Paste Canvas Layer, inline canvas etc, confuses newbies from the first day. The simple logic would tell the newbie that "Encapsulate" produces a "Capsule" and now a weird "Paste Canvas layer". If we go to Group by encapsulate and Set by Groups, we need to change the metaphor of the icon of the Group, Add to Group and Remove from Group. Also the capsule icon for the Paste Canvas layer and the Encapsulate action icon should be changed to something different (perhaps go back to the old brown paste canvas folder icon. Also it might be needed to change Paste Canvas layer to Group layer. That would make more sense.

I would like to add one new one:
CPoint (formerly Color Point) should be changed to Color stop as in all applications.

I'm sorry for not being so helpful giving strong decisions on which to use.

-G

De: Timothée Giet <animtim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Para: synfig-devl-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Enviado: Viernes 11 de Mayo de 2012 15:22
Asunto: Re: [Synfig-devl] Hi Synfig devs

Cool, I'm glad you agree with this Genete.
About the variables names, I don't have much to say as I don't really code myself, so it's up to you to decide if it's needed.

Thanks for the list Zelgadis, here is my opinion:

-Duck → Control point = OK (Although the name of Ducks will probably stay in my mind a long time now… was kinda funny :D )
-Curves Panel → I propose "Parameter-Animation-Curves", or just "Parameter Curves" (I thought about having a name like IPO curves in blender as it looks similar, although for now in synfig it's only a visual representation,(right?!) no control/handles on it directly, so is not an "IPO", but still a curve). Parameter Graph would be fine too.
-Bline → I propose "Path" , more precise than Curve in our context as it can be used to draw different kinds of Paths, and is also better to replace in "Create Curve gradient Bline" for example ;) .
-Groups → Sets OK (I agree as its a special way to group items, different from the common understanding of layer groups in other softs or like we have we have in encapsulating, so better to use another word; and "Sets" does fit the pupose to make some sets of layer types).
-Encapsulate → Group half OK, though I did like the capsule analogy… it illustrates well to me the fact that each capsule isolates its content from the rest, more than the generic "group" word.
So if some else want to keep the encapsulate terminology (and maybe then we can use the term "capsule" for the group, as represented by its icon)…
But if everyone wants to go for "To Group" in "Groups", then I'm fine with it.

Waiting your comments
Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/synfig-devl


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Zelgadis | 13 May 09:44 2012
Picon

Re: Hi Synfig devs

2012/5/13 Carlos Lopez Gonzalez <carloslopezgonzalez <at> yahoo.es>:
> Hi!
> here are my thoughts:
> Duck: this name caused troubles from the first day and it should be fit in
> some way. Control point is ok. Perhaps for BLines's vertices it is perfect
> but for other kind of parameters it is not full perfect. What about
> "Handle"?. It is just a suggestion because I like Control point.

I like "control point" too.

> Curves panel: I'm unsure about this. Graphs panel is the most liked by me.

Yes, my vote is for Graphs panel too.
"Parameter-Animation-Curves", or just "Parameter Curves" - looks too
complex and... there is "curves".

> BLine: I prefer Curve. The "Create curve gradient BLine" is wrong. It should
> be "Create curved Gradient Layer". There are some mistakes on the English
> version of the BLine tool. But on the other hand "Path tool" sounds better
> than "Curve tool" :-/

I don't like path, because it have double meaning when you deal with
animation. "Path" can be treated as trajectory - this is not good.

> -Encapsulate → Group half OK, though I did like the capsule analogy… it
> illustrates well to me the fact that each capsule isolates its content from
> the rest, more than the generic "group" word.

Yes, it illustrates. But the "encapsulate" is less intuitive for most users.

> Groups & Encapsulate: I like both like they are now. I think that the
> problem is that all that slang of Paste Canvas Layer, inline canvas etc,
> confuses newbies from the first day.

The thing is that we started to talk about terminology is because of
our conversation with Timothée after his talk. We were discussing
details and I have noticed that most of the time he says "Group"
instead of "Encapsulate". I've pointed that this could be confusing.
Also I remebered other people that use such term in casual talk.
That's how this "terminology rethinking" theme have been brought up.

> The simple logic would tell the newbie
> that "Encapsulate" produces a "Capsule" and now a weird "Paste Canvas
> layer". If we go to Group by encapsulate and Set by Groups, we need to
> change the metaphor of the icon of the Group, Add to Group and Remove from
> Group.

I don't see problem - the current group icons fit  well with"sets"
terminology as well.

> Also the capsule icon for the Paste Canvas layer and the Encapsulate
> action icon should be changed to something different (perhaps go back to the
> old brown paste canvas folder icon.

Yes. And in fact I like the "old brown" icon better, because it looks
more intuitive (from my point of view).

> Also it might be needed to change Paste
> Canvas layer to Group layer. That would make more sense.

Agree.

> I would like to add one new one:
> CPoint (formerly Color Point) should be changed to Color stop as in all
> applications.

Yes, we should add this to the list.

K.

> ________________________________
> De: Timothée Giet <animtim <at> gmail.com>
> Para: synfig-devl <at> lists.sourceforge.net
> Enviado: Viernes 11 de Mayo de 2012 15:22
> Asunto: Re: [Synfig-devl] Hi Synfig devs
>
> Cool, I'm glad you agree with this Genete.
> About the variables names, I don't have much to say as I don't really code
> myself, so it's up to you to decide if it's needed.
>
> Thanks for the list Zelgadis, here is my opinion:
>
> -Duck → Control point = OK (Although the name of Ducks will probably stay in
> my mind a long time now… was kinda funny :D )
> -Curves Panel → I propose "Parameter-Animation-Curves", or just "Parameter
> Curves" (I thought about having a name like IPO curves in blender as it
> looks similar, although for now in synfig it's only a visual
> representation,(right?!) no control/handles on it directly, so is not an
> "IPO", but still a curve). Parameter Graph would be fine too.
> -Bline → I propose "Path" , more precise than Curve in our context as it can
> be used to draw different kinds of Paths, and is also better to replace in
> "Create Curve gradient Bline" for example ;) .
> -Groups → Sets OK (I agree as its a special way to group items, different
> from the common understanding of layer groups in other softs or like we have
> we have in encapsulating, so better to use another word; and "Sets" does fit
> the pupose to make some sets of layer types).
> -Encapsulate → Group half OK, though I did like the capsule analogy… it
> illustrates well to me the fact that each capsule isolates its content from
> the rest, more than the generic "group" word.
> So if some else want to keep the encapsulate terminology (and maybe then we
> can use the term "capsule" for the group, as represented by its icon)…
> But if everyone wants to go for "To Group" in "Groups", then I'm fine with
> it.
>
> Waiting your comments
> Tim
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Synfig-devl mailing list
> Synfig-devl <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/synfig-devl
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Synfig-devl mailing list
> Synfig-devl <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/synfig-devl
>

--

-- 
http://morevnaproject.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Timothée Giet | 13 May 12:51 2012
Picon

Re: Hi Synfig devs

So for now we agree on:

-Control points : OK  (genete: I like the "handle" idea too, but let's shoose "control point" if everyone agree… is still more precise, and I think it works well also for all kind of points, as they are still here to control something. And it fits Inkscape terminology. On this point I think now it's even more important to get terminology compatible with Inkscape as much as possible, if we want to support the "Inkscape to synfig" export workflow…)

-Graph panel : OK (I agree it's the best suggestion here)

-Cpoint → Color Stop : Ok sure :)

-Encapsulate and Paste canvas layer→ Group and Group Layer : OK (indeed even for me it's the most intuitive term to use here)
-Groups → Sets  : so OK (about the icons, I agree to get back the brown icon for the layer groups, and for the sets as Zelgadis I think current icons could stay, not really a problem… but if you really want some new ones Genete, I can make some ;) )

Now about Bline→ Curve or Path , Path still looks the best choice to me… As genete said, "Path tool" sounds better; about confusion with animation path Zelgadis said, it makes me even more think that path is the right word as you can animate following a path… it makes sense. Also again it fits Inkscape /general vector tools terminology, so it would be good to use this word. But if you two prefer Curve, let's use it, I agree it's a hard choice… Checking the "Bezier curve" wikipedia page carefully, both terms could fit.

Waiting for you two (and if any other have something to say about this…) to confirm (or not) the list, and give your final choices.


Tim


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Yu Chen | 13 May 15:18 2012
Picon

Re: Hi Synfig devs

Hi

1)
Regarding encapsulate and group, I have to point out that synfig layer is primitive layer, in other graphics softwares in the world, 
they are normally defined as objects, take a look at Adobe Illustrator or Inkscape. There is another key point I have to mention capsulated 
layers are not 100% the same as group layers in other software, a capsulated layer is a canvas (exported or inline) in fact in synfig world. If
we rename it to group, a user (newbie) will still expect it behaves as in other graphic softwares. so from my point of view this renaming can 
not solve the  problem we are trying to solve. 

Yes, I redesigned group and inline canvas icons[1], there was some facts when I did them: I didn't know what exactly the inline canvas and
group meaning in synfig, as most of newbies come from other graphics world, you can see at the forum discussions, I made a proposal 
using a "Folder" metaphor for inline canvas and for group too. From this mistake I made, we can have some valuable things: renaming 
inline canvas/encapsulate to Group can help but impede a user to catch synfig concept quickly. We all have to agree that "ease to learn" is
not our main target since doing full feature animation movie with computer is not a ease job. 


If we finally make the decision that we have to rename encapsulate to group, group to sets, it will fine to me. but I can't agree with 
"keeping the current group icon as sets icon". Imaging a newbie come from other graphics software which has group layer concept as
in the most graphics software,  s/he except the "sets" behaves as group layer since most softwares use "Folder" icon as group layer.

From UX point of view (I am doing researching job for UI Redesign), Group concept in current synfig will be replace be a filter system of 
layers, I have some initial ideas in my mind: each layer can be tagged by user, and can be filtered. I will find time to draw some mockups
and post in here or forums to brainstorm.

2)
For BLine, I have one proposal : just use "Line". Curve is fine to me too, be based on my experience, if I saw a word curve, I will always
expect the line is a non-straight line :) BLine can be a straight line, isn't it?


Just my two cents.




~ yu



2012/5/13 Timothée Giet <animtim <at> gmail.com>
So for now we agree on:

-Control points : OK  (genete: I like the "handle" idea too, but let's shoose "control point" if everyone agree… is still more precise, and I think it works well also for all kind of points, as they are still here to control something. And it fits Inkscape terminology. On this point I think now it's even more important to get terminology compatible with Inkscape as much as possible, if we want to support the "Inkscape to synfig" export workflow…)

-Graph panel : OK (I agree it's the best suggestion here)

-Cpoint → Color Stop : Ok sure :)

-Encapsulate and Paste canvas layer→ Group and Group Layer : OK (indeed even for me it's the most intuitive term to use here)
-Groups → Sets  : so OK (about the icons, I agree to get back the brown icon for the layer groups, and for the sets as Zelgadis I think current icons could stay, not really a problem… but if you really want some new ones Genete, I can make some ;) )

Now about Bline→ Curve or Path , Path still looks the best choice to me… As genete said, "Path tool" sounds better; about confusion with animation path Zelgadis said, it makes me even more think that path is the right word as you can animate following a path… it makes sense. Also again it fits Inkscape /general vector tools terminology, so it would be good to use this word. But if you two prefer Curve, let's use it, I agree it's a hard choice… Checking the "Bezier curve" wikipedia page carefully, both terms could fit.

Waiting for you two (and if any other have something to say about this…) to confirm (or not) the list, and give your final choices.


Tim



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Yu Chen | 13 May 15:26 2012
Picon

Re: Hi Synfig devs

typo:

>>>renaming inline canvas/encapsulate to Group can help but impede a user to catch synfig concept quickly.

renaming inline canvas/encapsulate to Group can not help but impede a user to catch synfig concept quickly.

~ yu



2012/5/13 Yu Chen <jcomee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi

1)
Regarding encapsulate and group, I have to point out that synfig layer is primitive layer, in other graphics softwares in the world, 
they are normally defined as objects, take a look at Adobe Illustrator or Inkscape. There is another key point I have to mention capsulated 
layers are not 100% the same as group layers in other software, a capsulated layer is a canvas (exported or inline) in fact in synfig world. If
we rename it to group, a user (newbie) will still expect it behaves as in other graphic softwares. so from my point of view this renaming can 
not solve the  problem we are trying to solve. 

Yes, I redesigned group and inline canvas icons[1], there was some facts when I did them: I didn't know what exactly the inline canvas and
group meaning in synfig, as most of newbies come from other graphics world, you can see at the forum discussions, I made a proposal 
using a "Folder" metaphor for inline canvas and for group too. From this mistake I made, we can have some valuable things: renaming 
inline canvas/encapsulate to Group can help but impede a user to catch synfig concept quickly. We all have to agree that "ease to learn" is
not our main target since doing full feature animation movie with computer is not a ease job. 


If we finally make the decision that we have to rename encapsulate to group, group to sets, it will fine to me. but I can't agree with 
"keeping the current group icon as sets icon". Imaging a newbie come from other graphics software which has group layer concept as
in the most graphics software,  s/he except the "sets" behaves as group layer since most softwares use "Folder" icon as group layer.

From UX point of view (I am doing researching job for UI Redesign), Group concept in current synfig will be replace be a filter system of 
layers, I have some initial ideas in my mind: each layer can be tagged by user, and can be filtered. I will find time to draw some mockups
and post in here or forums to brainstorm.

2)
For BLine, I have one proposal : just use "Line". Curve is fine to me too, be based on my experience, if I saw a word curve, I will always
expect the line is a non-straight line :) BLine can be a straight line, isn't it?


Just my two cents.




~ yu



2012/5/13 Timothée Giet <animtim <at> gmail.com>
So for now we agree on:

-Control points : OK  (genete: I like the "handle" idea too, but let's shoose "control point" if everyone agree… is still more precise, and I think it works well also for all kind of points, as they are still here to control something. And it fits Inkscape terminology. On this point I think now it's even more important to get terminology compatible with Inkscape as much as possible, if we want to support the "Inkscape to synfig" export workflow…)

-Graph panel : OK (I agree it's the best suggestion here)

-Cpoint → Color Stop : Ok sure :)

-Encapsulate and Paste canvas layer→ Group and Group Layer : OK (indeed even for me it's the most intuitive term to use here)
-Groups → Sets  : so OK (about the icons, I agree to get back the brown icon for the layer groups, and for the sets as Zelgadis I think current icons could stay, not really a problem… but if you really want some new ones Genete, I can make some ;) )

Now about Bline→ Curve or Path , Path still looks the best choice to me… As genete said, "Path tool" sounds better; about confusion with animation path Zelgadis said, it makes me even more think that path is the right word as you can animate following a path… it makes sense. Also again it fits Inkscape /general vector tools terminology, so it would be good to use this word. But if you two prefer Curve, let's use it, I agree it's a hard choice… Checking the "Bezier curve" wikipedia page carefully, both terms could fit.

Waiting for you two (and if any other have something to say about this…) to confirm (or not) the list, and give your final choices.


Tim



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/synfig-devl



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Timothée Giet | 21 May 14:06 2012
Picon

Re: Hi Synfig devs

2012/5/13 Yu Chen <jcomee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi

1)
Regarding encapsulate and group, I have to point out that synfig layer is primitive layer, in other graphics softwares in the world, 
they are normally defined as objects, take a look at Adobe Illustrator or Inkscape. There is another key point I have to mention capsulated 
layers are not 100% the same as group layers in other software, a capsulated layer is a canvas (exported or inline) in fact in synfig world. If
we rename it to group, a user (newbie) will still expect it behaves as in other graphic softwares. so from my point of view this renaming can 
not solve the  problem we are trying to solve. 


Ok, so there are good reasons to keep the encapsulate terminology, to mark the difference with groups in other softwares.
I agree with this.
But then the current "Groups" in synfig don't act like groups in other softwares neither. So it's again a bit confusing for the user (I've been quite confused about this the first time I saw this new panel)
So I still think we should rename those "group" to "Set", to mark the difference.
And then I agree that some different icons are needed for those.
 

Yes, I redesigned group and inline canvas icons[1], there was some facts when I did them: I didn't know what exactly the inline canvas and
group meaning in synfig, as most of newbies come from other graphics world, you can see at the forum discussions, I made a proposal 
using a "Folder" metaphor for inline canvas and for group too. From this mistake I made, we can have some valuable things: renaming 
inline canvas/encapsulate to Group can help but impede a user to catch synfig concept quickly. We all have to agree that "ease to learn" is
not our main target since doing full feature animation movie with computer is not a ease job. 


If we finally make the decision that we have to rename encapsulate to group, group to sets, it will fine to me. but I can't agree with 
"keeping the current group icon as sets icon". Imaging a newbie come from other graphics software which has group layer concept as
in the most graphics software,  s/he except the "sets" behaves as group layer since most softwares use "Folder" icon as group layer.

From UX point of view (I am doing researching job for UI Redesign), Group concept in current synfig will be replace be a filter system of 
layers, I have some initial ideas in my mind: each layer can be tagged by user, and can be filtered. I will find time to draw some mockups
and post in here or forums to brainstorm.

2)
For BLine, I have one proposal : just use "Line". Curve is fine to me too, be based on my experience, if I saw a word curve, I will always
expect the line is a non-straight line :) BLine can be a straight line, isn't it?



Line is indeed more accurate than curve as it can be straight as you said. But it's also a very "generic" term.
In a discussion with Genete, he proposed "Spline", and I like this proposal
(actually I thought about this too before but I wasn't sure if it was really correct, but now I know it is :) )
 
 
Just my two cents.

Thanks for those, very useful!


So to summarize, we have now these proposals where we all agree:

-For "Ducks" : "Control points" - OK

-For  "Curves panel" : "Graph panel" - OK

-For "Cpoint" → "Color Stop" : OK


And on these we still have to choose:

-"Encapsulate" : "Group" or no change (I vote for no change, and so keep the green capsules icons)

-"Group": "Set" or no change (I vote for Set, and get new icons of course)

-"Bline": "Curve", "Path", "Line", "Spline" (I vote for Spline)


I propose everyone say now his choice on these (let's wait one week from now before we close the topic, so everyone can take time to answer), and then we choose the most wanted.


Tim
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
David Rylander | 21 May 14:41 2012
Picon

Re: Hi Synfig devs

...
>
>
> So to summarize, we have now these proposals where we all agree:
>
> -For "Ducks" : "Control points" - OK
>
> -For "Curves panel" : "Graph panel" - OK
>
> -For "Cpoint" → "Color Stop" : OK
I'm fine with all these propositions, will make it more clear I think.
>
> And on these we still have to choose:
>
> -"Encapsulate" : "Group" or no change (I vote for no change, and so 
> keep the green capsules icons)
How about "Capsule"? I think it's more direct and more easily understood 
by non english speakers. It also bring up a mental image of a capsule, 
like our icon. How does an encapsule look?
To select several layers and bring them together in a capsule can still 
be called "encapsulate". I think some of the confusing also stems from 
this encapsulate/encapsule. encapsulate/capsule sounds more distinct in 
my ears.
Group can work, but as pointed out before, it is more than just a group, 
it is a canvas of it's own.

We scrap the use of paste canvas and inline canvas which is plain confusing.
>
> -"Group": "Set" or no change (I vote for Set, and get new icons of course)
Set sounds great. Or selection groups.
>
> -"Bline": "Curve", "Path", "Line", "Spline" (I vote for Spline)
Not sure about this. I think bline is rather good. It doesn't have a 
different meaning in other software or contexts and it doesn't take very 
long to learn what it means in Synfig.
Path is definitely not a good name, I see paths of action before me or 
paths which objects follow.
With Spline I see vector curves used for altering animation in graph 
editors in 3D softwares.

Another think that is slightly confusing is "params" which is not a real 
word. Googling gives that it's sometimes used as slang for parameters in 
different prorgamming languages.
For non programmer users I think we can change to using "parameters panel".

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Zelgadis | 21 May 15:09 2012
Picon

Re: Hi Synfig devs

Hi!
That's me again. ^__^

2012/5/13 Yu Chen <jcomee@...>:
> Hi
>
> 1)
> Regarding encapsulate and group, I have to point out that synfig layer
> is primitive layer, in other graphics softwares in the world,
> they are normally defined as objects, take a look at Adobe Illustrator or
> Inkscape. There is another key point I have to mention capsulated
> layers are not 100% the same as group layers in other software, a capsulated
> layer is a canvas (exported or inline) in fact in synfig world. If
> we rename it to group, a user (newbie) will still expect it behaves as in
> other graphic softwares. so from my point of view this renaming can
> not solve the  problem we are trying to solve.
>
> Yes, I redesigned group and inline canvas icons[1], there was some facts
> when I did them: I didn't know what exactly the inline canvas and
> group meaning in synfig, as most of newbies come from other graphics world,
> you can see at the forum discussions, I made a proposal
> using a "Folder" metaphor for inline canvas and for group too. From this
> mistake I made, we can have some valuable things: renaming
> inline canvas/encapsulate to Group can help but impede a user to catch
> synfig concept quickly. We all have to agree that "ease to learn" is
> not our main target since doing full feature animation movie with computer
> is not a ease job.

I understand, that "Encapsulated layer" in synfig is not the same as
group in other software.
BUT, I still insist  on renaming to Group and I have a reason for that.
Let me share with you my experience of teaching Synfig to kids (age of
14 - 17 years old).
I do that for 2,5 years already and I can say for sure, that word
"Encapsulate" doesn't say anything to them. As well as "Capsule".
When I say: "You need to encapsulate those objects" - kids stay confused.
But when I say "Hey, let's group those layers together" - they have no
problems with understanding.
After that all I need to mention is that "all those filter layers like
"Blur", "Twirl" can not influence outside the group". And this is
perfectly fine for them to understand. The "scope limit" becomes just
another property.

It's proven that there's nothing in such approach preventing kids to
understand the concepts. And thus for users as well.

Don't get me wrong, Yu, I love all the work you did on icons redesign.
I just don't like the "capsule" concept as it's harder to understand
and explain from my experience. ^__^

> If we finally make the decision that we have to rename encapsulate to group,
> group to sets, it will fine to me. but I can't agree with
> "keeping the current group icon as sets icon". Imaging a newbie come from
> other graphics software which has group layer concept as
> in the most graphics software,  s/he except the "sets" behaves as group
> layer since most softwares use "Folder" icon as group layer.

> From UX point of view (I am doing researching job for UI Redesign), Group
> concept in current synfig will be replace be a filter system of
> layers, I have some initial ideas in my mind: each layer can be tagged by
> user, and can be filtered. I will find time to draw some mockups
> and post in here or forums to brainstorm.

I see now. Yes, it's better to redesign Group/Set icons.
Also, you right - the "Groups/Sets" are exactly the same as the "Tag".

2012/5/13 Yu Chen <jcomee@...>:
> 2)
> For BLine, I have one proposal : just use "Line". Curve is fine to me too,
> be based on my experience, if I saw a word curve, I will always
> expect the line is a non-straight line :) BLine can be a straight line,
> isn't it?

2012/5/21 Timothée Giet <animtim@...>:
> Line is indeed more accurate than curve as it can be straight as you said.
> But it's also a very "generic" term.
> In a discussion with Genete, he proposed "Spline", and I like this proposal
> (actually I thought about this too before but I wasn't sure if it was really
> correct, but now I know it is :) )

2012/5/21 David Rylander <rylleman@...>:
> Not sure about this. I think bline is rather good. It doesn't have a
> different meaning in other software or contexts and it doesn't take very
> long to learn what it means in Synfig.
> Path is definitely not a good name, I see paths of action before me or
> paths which objects follow.
> With Spline I see vector curves used for altering animation in graph
> editors in 3D softwares.

About "BLine" - there's no such word at all. As well as "Param". It's a slang.
"Spline" is too mathematic-oriented.
"Line" looks too generic.
My vote is for "Curve". Just a personal preference. ^__^"

2012/5/21 David Rylander <rylleman@...>:
> Another think that is slightly confusing is "params" which is not a real
> word. Googling gives that it's sometimes used as slang for parameters in
> different prorgamming languages.
> For non programmer users I think we can change to using "parameters panel".

Yes, I totally agree.

Cheers!
K.

--

-- 
http://morevnaproject.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
David Rylander | 21 May 15:25 2012
Picon

Re: Hi Synfig devs

2012-05-21 15:09, Zelgadis skrev:
> I understand, that "Encapsulated layer" in synfig is not the same as
> group in other software.
> BUT, I still insist  on renaming to Group and I have a reason for that.
> Let me share with you my experience of teaching Synfig to kids (age of
> 14 - 17 years old).
I change my mind. I agree with Konstantin. He has a very valid point.

Groups is much, much easier to understand and more consistent with other 
software.
They are immediately understood which is not the case with capsules.

How do we handle the changes. Now we will have very huge changes in what 
things are called in Synfig, in some cases even new functions for old 
names (groups).
There are bound to be users coming to the forums with older versions and 
being told new way of doing things or people with older versions going 
to the wiki and getting very, very confused.

-David

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Zelgadis | 21 May 17:33 2012
Picon

Re: Hi Synfig devs

2012/5/21 David Rylander <rylleman@...>:
> 2012-05-21 15:09, Zelgadis skrev:
>> I understand, that "Encapsulated layer" in synfig is not the same as
>> group in other software.
>> BUT, I still insist  on renaming to Group and I have a reason for that.
>> Let me share with you my experience of teaching Synfig to kids (age of
>> 14 - 17 years old).
> I change my mind. I agree with Konstantin. He has a very valid point.
>
> Groups is much, much easier to understand and more consistent with other
> software.
> They are immediately understood which is not the case with capsules.
>
> How do we handle the changes. Now we will have very huge changes in what
> things are called in Synfig, in some cases even new functions for old
> names (groups).
> There are bound to be users coming to the forums with older versions and
> being told new way of doing things or people with older versions going
> to the wiki and getting very, very confused.

Yes, that's the reason why we need to do that sooner. The more we
postpone that reorganization -  the more problems we will have (amount
of posts on the forum is growing, we have more and more new users,
more documentation...).

I think Carlos will agree to handle changes in code (change only
labels, not variables).
I can take responsibility for changes in documentation. But I will
need help of you all to review the wiki pages (we can split the data
into parts, for example I will review pages starting with A-H, someone
else - H-O, etc...)
Forums will stay untouched.
The problem is that the changes in documentation need to be done
quickly and this process should be synced with the release. Changing
and reviewing documentation is a LOT of work. I think we can fit that
into one week.

So we need to define our schedule.
I will be available in periods 10-30 June and 10 July - 30 August. (On
summer I will be working on Morevna, but I will be able to fit one
week of documentation + release routines).
My suggestion is to plan release on 30 June or 30 July and work on
documentation changes a week before the release.
K.

--

-- 
http://morevnaproject.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Timothée Giet | 21 May 17:45 2012
Picon

Re: Hi Synfig devs

Actually I change my mind too, I do agree with Konstantin.
Also I don't know in other (proprietary) softwares, but at least in Krita, layer groups act exactly the same
(meaning a filter layer has effect only on layers below in the group, same for alpha lock etc… )
so it is consistent to call them groups in my point of view.

So my final choices are:

-"Encapsulate" : "Group"

-"Group": "Set"

-"Bline": "Spline" (but I agree that Bline did the job, just it's not a "real word" (http://en.wikipedia.org/wiki/B_Line) )


True the changes must be done quick and all-at-the-same time.
Also a big warning notice on the website frontpage, the forums, etc… to warn everyone.

Konstantin's plan sounds good. I can take a part of the doc to fix.
Konstantin, can you organize this (count how much people are doing it, then split the work and assign it to each person…)?

I'll probably be more available on June, but July could work too for me.


Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Zelgadis | 21 May 18:17 2012
Picon

Re: Hi Synfig devs

2012/5/21 Timothée Giet <animtim@...>:
> -"Bline": "Spline" (but I agree that Bline did the job, just it's not a
> "real word" (http://en.wikipedia.org/wiki/B_Line) )

With "Spline" we fall into the same situation as with "Encapsulate"
thing - If user have no knowledge of high-mathematics, then "Spline"
term should be explained: "Spline is just a curve thing". ^__^

> Also a big warning notice on the website frontpage, the forums, etc… to warn
> everyone.

Good idea.

> Konstantin's plan sounds good. I can take a part of the doc to fix.
> Konstantin, can you organize this (count how much people are doing it, then
> split the work and assign it to each person…)?

Yes, I can take organization of documentation review.
I need to know who else is willing to help and their availability/schedule.
Also I will need a final word from Carlos about code changes.

K.

--

-- 
http://morevnaproject.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Timothée Giet | 21 May 18:40 2012
Picon

Re: Hi Synfig devs



2012/5/21 Zelgadis <ksee.zelgadis <at> gmail.com>
2012/5/21 Timothée Giet <animtim <at> gmail.com>:
> -"Bline": "Spline" (but I agree that Bline did the job, just it's not a
> "real word" (http://en.wikipedia.org/wiki/B_Line) )

With "Spline" we fall into the same situation as with "Encapsulate"
thing - If user have no knowledge of high-mathematics, then "Spline"
term should be explained: "Spline is just a curve thing". ^__^


Well as a reference, in the only proprietary animation software I ever owned and used (TVPaint), the tool to draw vector curves is called Spline tool, and everyone is fine with it, even if almost nobody has advanced math knowledge.

And if a user asks, is a good time for him to learn what is a spline in general, not only in synfig.
That's the difference with the encapsulate term, which in the absolute is a real word but the meaning we gave it was synfig-specific.

In short, Spline=vector path/curve, but the word is more elegant in my taste, and still very appropriate in its common meaning.
Also a "Curve" or "Line" tool, how is it different from the draw tool? that makes curves and lines too… So calling it Spline tool marks better the usecase.
I've noticed it's rarely a good idea to use too generic terms, so avoiding them will prevent some future confusions.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Yu Chen | 21 May 20:58 2012
Picon

Re: Hi Synfig devs


2012/5/21 Timothée Giet <animtim <at> gmail.com>
Actually I change my mind too, I do agree with Konstantin.
Also I don't know in other (proprietary) softwares, but at least in Krita, layer groups act exactly the same
(meaning a filter layer has effect only on layers below in the group, same for alpha lock etc… )
so it is consistent to call them groups in my point of view.

:) Let me dig it more.

I did some research last week, 

firstly I took famous vector based graphics softwares: Illustrator, Inkscape, and toonboom animatepro. 

== Illustrator & Inkscape ==
There is not group layer concept in Illustrator, Inkscape. in these two software, if you group two or more objects, these objects(if they are separated in different layers) will be moved into a certain layer.


== Toonboom AnimatePro==
There are two group actions: 
1) group : to group primitive objects which are in the SAME layer only.
2) group layers : to group layers.

"group layers" is quite similar to our "Layer Group Assuming", but there is a "ungroup grouped layers", with it you can ungroup layers without any effect on your artwork content. So it behaves more or less same to synfig's current Group concept.


Then, bitmap graphics software, Gimp and Photoshop were token

==Gimp & Photoshop==
There is group layer concept in the both software, and they are almost the same, you can have alpha, blend mode for group layers for example. And there is not group concept in object level, you can not group two objects in a layer for example.


==Synfig Studio==
1)The layer is primitive, 
2) No group layer concept but an encapsulate layer can take over "Group" 
3) Encapsulate is more than group layer in other  software
4) There is a group panel that can do similar job than group action in vector based software.


In all graphics softwares mentioned above, no matter it is vector based or bitmap based, their layer is totally different than Synfig, or we can say their layers is more advanced than Synfig layer. In these software, one layer can contain multiple objects. But in Synfig, an object is a layer, so we can have the following map:

Other Vector Software vs Synfig Studio
Objects == Layers
Layers == Encapsulate Layers
Groups == Groups

Other Bitmap Software vs Synfig Studio
Objects == Layers
Layers == Encapsulate Layers
Group Layers == Multilevel Encapsulate Layers

As we discussed before, Encapsulate Layer is more than "Group Layer" in other softwares. Let me quote words from wiki: "A canvas is simply an ordered list of layers", "When you encapsulate a group of layers, you are making a new Canvas"[1]. 

A typical Synfig document (sif, sifz) is consist of a root canvas and sub-canvases(inline & exported). And those sub-canvases are existing as Encapsulate layers currently.


I can not come to a conclusion that if renaming Encapsulate to Group or not. The main intending of this researching is to have a more detail references, and hopefully it helps us on this renaming disscussion.


From my opinion, since in Synfig, the layer is a big different than others, and the canvas and sub-canvases (exported canvases) are so important in synfig animation world, for a user, it is valueable for a user taking his time to get this different concepts at the very begining. 

We have to keep in mind that layers is abused somehow in current version, we can take a look at those sifz files posted in our forums by artists, maybe, just maybe, one day after we have to consider how to improve this situation, if I remember correctly, there is a topic regarding this. 

Having these in mind, there is a new idea(just an idea) bring up: we can rename Encapsulate Layer to Sub-Canvas Layer, and the Encapsulate tool in layer panel can be renamed to Capsulate or Group or Pack, that says, if you capsualte or group or pack layers, at the same time those layers will be placed in a new sub-canvas. It helps user to catch the concept of Encapsulate Layer, a canvas / sub-canvas is an island similar to group in other graphic softwares somehow, and it indentifies it is a canvas, it can be inline or exported.

With this, we can implement/change layer creation behavior to close the most graphics software in the word: new file will always come with a new sub-canvas layer, by default, all new primitive layers (objects) you created will be placed in this new sub-canvas untill you create a second sub-canvas layer. In this way, we don't need to change the system architecture of synfig.


And please don't make me wrong, I can accept renaming encapsulate to group, in fact, wfor the first time, I fired up Synfig Studio and tried to find a group button on layer panel, clicked the "brownish pack" icon, I expected there would be a layer named "Group 01" appear in layer panel.
 



 
So my final choices are:

-"Encapsulate" : "Group"

-"Group": "Set"

-"Bline": "Spline" (but I agree that Bline did the job, just it's not a "real word" (http://en.wikipedia.org/wiki/B_Line) )


True the changes must be done quick and all-at-the-same time.
Also a big warning notice on the website frontpage, the forums, etc… to warn everyone.

Konstantin's plan sounds good. I can take a part of the doc to fix.

I can take some tasks too, but I can't promise too much since my poor english :)


Cheers!

~yu

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Timothée Giet | 22 May 00:31 2012
Picon

Re: Hi Synfig devs

Interesting research Yu, but I still think that whe should rename encapsulate to group.
Here's my point:

-Layers are meant to organize the visual ordering of the composition (which object is above or below the other…compositing) (Ok, compared to other softwares, our layers here are limited to 1 object/layer, but I think it has more to do with how one must conceive his drawing than with the question here. Basically Layers are still composited the same way)

-Encapsulate/group are meant to bundle some layers together so that they get grouped together; all the compositing attributes inside it (blend modes, alpha, fxs) affect only the current group, and you can transfrom them all together too…  Then the whole content result is composited using the "master" group blending mode (I say master group because I often have several levels of groups :P ).
In more simple words: it makes a bundle of layers that is then treated as a single layer in the layer stack compositing; in this definition it's exactly as in other softwares which have a layer group feature. 

-Goup/Set are meant to toggle visibility of different elements spread accross the layer stack. It is a feature quite specific to synfig (although as you mentionned, the "ungroup layer" from toon boom seems to have similar usecase, but with a completly different workflow) so it deserves a specific term.

"A typical Synfig document (sif, sifz) is consist of a root canvas and sub-canvases(inline & exported). And those sub-canvases are existing as Encapsulate layers currently."
This is more a technical point that doesn't need to be directly exposed to the user. This is quite logical that if I import an element from another file, it will be contained in a separate independant group.


The fact that 1 layer=1object is specific in Synfig design, but actually in many worflows on other softwares produce the same result (I think of people I know doing color work with photoshop, and they separate each object on separate layers, to shade them easier/faster… so they end with 1object/layer exactly like in a synfig file ;) ). So this synfig design is more a "restriction" of layer usage than a really different thing. It's still a layer, containing some color pixels (produced by vector shapes or FXs…), composited on top of other layers. In the basics it's still the same thing. And this restriction is good in a way because it force the user to separate his drawing in different elements, that can be animated independantly easier then.

So now it's up to everyone here to say what they think is best.
I already told my preferences, I think I won't change again my choice now.

We'll see what comes out when everyone has answered :)

Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Nikita Kitaev | 22 May 06:48 2012
Picon

Re: Hi Synfig devs

I like the suggestions here. From the current list, I agree with:
Cpoint -> Color Stop
Encapsulate -> Group
Groups -> Sets

"Control points" seems too long for such a common term: especially in
phrases like "tangent control point". Shortening it to "controls" or
just "points" may not work ("controls" is ambiguous, "tangent point"
has a different meaning). I suggest Handles, Nodes, or Anchors.

For BLine I like "Spline" the most, but it still seems technical. What
about making the name less prominent? (Shape tool/Outline layer/Region
layer, and use Spline only in the parameter panel)

Also, some more suggestions:
Children panel -> Library (Upgrading it to function more like a
"library" in other tools wouldn't hurt too)
Import -> Place (Following a convention from desktop publishing:
"place" a JPEG vs. "import" an SVG. "Place" implies embedding,
"import" implies a file format conversion)

~Nikita

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Carlos Lopez Gonzalez | 22 May 09:00 2012
Picon
Picon

Re: Hi Synfig devs

Hi guys!
First sorry for miss the interesting conversation hold yesterday but I was distracted working on Cairo implementation strategy ^__^

Instead quote to each answer let me do a summary of the redefinition process, my preferences and thoughts.

Duck: I am with Nikitakit here. Although "Control point" is OK it is too long and works conceptually I do prefer something more synthetic and generic. Handle or Anchor are good candidates to me. Currently there are BLine point and Width point that refers to the group of ducks that belongs to a list item. This is related to the problem of rename BLine. I vore for Handle.

Curves panel: Graph panel. OK

CPoint: Color stop. OK

Encapsulate and Paste Canvas layer: Both concepts and its icons has to be reviewed. I vote for Encapsulate -> Group (as verb) and Paste Canvas layer -> Group layer (as noun).

Group: Set is OK

BLine: Say we call it Curve. It implies to call Curve point to the set of ducks that represent the current BLine point. So if we rename Duck to Control point we should say: "Then the user should select all the Curve point's Control points" instead of "Then the user selects all the BLine point's Ducks.". The second is more synthetic and better to understand to me. Curve point seems to mean that it lies on the curve and that's not true for a generic duck. Either we think on other name for "BLine point" (Curve item or similar) or we use a shorter term on Duck (like Handle or Anchor). I still preferring Spline. Spline implies geometry definition of a curve. But curve is also referred to a "action curve" in the traditional animation way or we can talk about graph curve when referring to whats is drawn on the now called Graph panel. There exists a "X,Y curve" (given a x obtain a y) but there doesn't exists a "X, Y spline" because the splines are defined in other way. My vote is for Spline. I don't see anything wrong with the fact that it is a math concept. IPO driver is also an abstract concept and everyone is happy with it. A Bezier curve or more generically a Spline is a new concept for most of people that is not used to computer vector graphics and use the right terms will help on further confusion on use the same word (curve) for other common items.

BLine point: Derived from above. We currently talk about BLine point's tangent duck as something easy to find and understand. Translated it would be: "Curve point's tangent Control point" too many points in my opinion. "Spline Item tangent's handle" sounds better to me. Well, everything sounds strange to me now! ^__^''

Params: Parameters

Children Panel: Library is ok. But we should then remove the Canvas panel and give its functionality to the Canvases list, which is currently useless.

Import: Place. The word "Place" looks strange to me in a menu entry. Import looks good to me and it does not imply a conversion except for SVG import which I think that is the wrong concept. Although SVG import module should be removed after SVG2SIF Inkscape's script, it can be renamed to SVG convert which is really what is happening.

Regarding to renaming implementation process I think that we should do it in one shot but without hurry up due to a new release. I don't plan to do a release soon. Unless someone come with some substantial commits and it deserves a release, the next release is planned with the new Cairo implementation as main change so it will take a while at the moment.

So resume is:

Duck: Handle
Curves panel: Graph panel
Encapsulate: Group
Paste Canvas layer: Group layer
Group: Set
BLine: Spline
BLine point: Spline item
Params: Parameters
Children: Library (and enable Canvases list there)
Import: no change.

Cheers!



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Yu Chen | 22 May 13:19 2012
Picon

Re: Hi Synfig devs


~ yu



2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez-mRCrAkd8dF0@public.gmane.org>
Hi guys!
First sorry for miss the interesting conversation hold yesterday but I was distracted working on Cairo implementation strategy ^__^

Instead quote to each answer let me do a summary of the redefinition process, my preferences and thoughts.

Duck: I am with Nikitakit here. Although "Control point" is OK it is too long and works conceptually I do prefer something more synthetic and generic. Handle or Anchor are good candidates to me. Currently there are BLine point and Width point that refers to the group of ducks that belongs to a list item. This is related to the problem of rename BLine. I vore for Handle.

Curves panel: Graph panel. OK

CPoint: Color stop. OK

Encapsulate and Paste Canvas layer: Both concepts and its icons has to be reviewed. I vote for Encapsulate -> Group (as verb) and Paste Canvas layer -> Group layer (as noun).
 

I am a bit sad, I have to say bye-bye to (Paste) Canvas Layer :( This is an unique indicator of Synfig differs to other graphics softwares. and it is/will a big actor (concept) in my UI redesign plan. Any way, I trust the choice what you guys do :) 

Regarding icons, there would be one more involved: canvas type of Paste Canvas Layer in Parameters panel. We can not just used Canvas Icon for canvas type, because Canvas Icon is a green ball as you can see, the circle shape already used by Vector type. So maybe we should redesign canvas icon as well, and the apply same metaphor to canvas type. Actually, when I redesigned these icons for various panels and types, I tried to redesign canvas icon, but I couldn't find a solution that satisfied me. 

The current one is based on the concept of encapsulate. The new _group layer_  and _group tool_ can take the folder icon used by current group panel, as we are trying to introduce _group concept_ in other bitmap based softwares. folder metaphor is used in Photoshop, AnimePro etc... 

Design a icon for the new Sets Panel is a challenge as well, since there is not other applications have this concept, use "Tag" icon sounds work, unfortunately, "Tag" icon exists in Synfig Studio as metaphor of metadata.


Cheers!  
 

Group: Set is OK

BLine: Say we call it Curve. It implies to call Curve point to the set of ducks that represent the current BLine point. So if we rename Duck to Control point we should say: "Then the user should select all the Curve point's Control points" instead of "Then the user selects all the BLine point's Ducks.". The second is more synthetic and better to understand to me. Curve point seems to mean that it lies on the curve and that's not true for a generic duck. Either we think on other name for "BLine point" (Curve item or similar) or we use a shorter term on Duck (like Handle or Anchor). I still preferring Spline. Spline implies geometry definition of a curve. But curve is also referred to a "action curve" in the traditional animation way or we can talk about graph curve when referring to whats is drawn on the now called Graph panel. There exists a "X,Y curve" (given a x obtain a y) but there doesn't exists a "X, Y spline" because the splines are defined in other way. My vote is for Spline. I don't see anything wrong with the fact that it is a math concept. IPO driver is also an abstract concept and everyone is happy with it. A Bezier curve or more generically a Spline is a new concept for most of people that is not used to computer vector graphics and use the right terms will help on further confusion on use the same word (curve) for other common items.

BLine point: Derived from above. We currently talk about BLine point's tangent duck as something easy to find and understand. Translated it would be: "Curve point's tangent Control point" too many points in my opinion. "Spline Item tangent's handle" sounds better to me. Well, everything sounds strange to me now! ^__^''

Params: Parameters

Children Panel: Library is ok. But we should then remove the Canvas panel and give its functionality to the Canvases list, which is currently useless.

Import: Place. The word "Place" looks strange to me in a menu entry. Import looks good to me and it does not imply a conversion except for SVG import which I think that is the wrong concept. Although SVG import module should be removed after SVG2SIF Inkscape's script, it can be renamed to SVG convert which is really what is happening.

Regarding to renaming implementation process I think that we should do it in one shot but without hurry up due to a new release. I don't plan to do a release soon. Unless someone come with some substantial commits and it deserves a release, the next release is planned with the new Cairo implementation as main change so it will take a while at the moment.

So resume is:

Duck: Handle
Curves panel: Graph panel
Encapsulate: Group
Paste Canvas layer: Group layer
Group: Set
BLine: Spline
BLine point: Spline item
Params: Parameters
Children: Library (and enable Canvases list there)
Import: no change.

Cheers!




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Timothée Giet | 22 May 14:20 2012
Picon

Re: Hi Synfig devs

Cool, more answers! :)

I agree control point is a bit long, handle is better.

Children Panel: Library is ok for me too.

Import: I like it like it is. "Place" sounds strange, import is more meaningful to me.

I agree with yu's suggestions regarding icons.
You're right there's different icons involved in this renaming:
"Encapsulate→Group"
"Canvas green icon"→"Group layer"
"Select all child layers"
"Canvas" parameter

"Set"
"Add layers to set"
"Remove layers from set"

About the "Canvas" line in parameters, true a good icon based on group icon concept could work. But we keep it named Canvas, as it's the canvas parameter of the group layer.
(Actually this is the remaining indication that you can use a group to import an external canvas ;) )

I'd be happy if you have some proposals for the new icons (I very much like the work you did before).


So I agree with all the resume from Genete, except " BLine point: Spline item" where I'm not sure.
The item term sounds strange, why not keep point → Spline point?
It would be consistent with width points.
Or then we should rename width point to width item too.

Cheers!
Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Zelgadis | 22 May 17:09 2012
Picon

Re: Hi Synfig devs

I like the "Library" suggestion! "File->Place" doesn't looks god for me.
For "Bline" I still like the "Curve", but after all arguments the
Spline is OK for me. Also I like Nikita's "Shape" alternative. In
fact, the more I think about it, the more I like "Shape" - "Shape
Tool" sounds good. But if everyone prefers Spline, that's ok for me
too. ^__^

2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez <at> yahoo.es>:
> Children Panel: Library is ok. But we should then remove the Canvas panel
> and give its functionality to the Canvases list, which is currently useless.

Let's don't mix too many goals at once. ^__^ I mean, let's concentrate
on terminology change and only after that - change all the rest
(canvases list, svg stuff, etc...) I mean we should go in small steps,
because terminology change is a lot of work already. ^__^

2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez <at> yahoo.es>:
> But curve is also referred to a "action curve" in the traditional animation way
> or we can talk about graph curve when referring to whats is drawn on the now
> called Graph panel. There exists a "X,Y curve"
In Graphs Panel we have Graphs, not Curves. ~_^ There's no "graph
curve", just a "graph".

2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez <at> yahoo.es>:
> ...if we rename Duck to
> Control point we should say: "Then the user should select all the Curve
> point's Control points" instead of "Then the user selects all the BLine
> point's Ducks.".
> ...
> BLine point: Derived from above. We currently talk about BLine point's
> tangent duck as something easy to find and understand. Translated it would
> be: "Curve point's tangent Control point" too many points in my opinion.
> "Spline Item tangent's handle" sounds better to me. Well, everything sounds
> strange to me now! ^__^''

Let's don't make things too complicated. I don't remember such strange
phrases like "Then the user selects all the BLine point's Ducks." in
documentation. Even if we have such ones, let's avoid them. Keep it
simple: "User should select a vertex together with its tangents". Or:
"User should select a vertex together with its tangent and width
handles". It's just a matter of good writing style. ^__^

In fact BLinePoint is a kind of internal concept that visible to user
only as the parameter type. He needs that definition only in
export/linking operation to distinguish vertex (as BLine Point
element) from the whole Bline point. We don't have "BLine Points" list
- it's called "Vertices". So we shouldn't use the BlinePoint in user
documentation very much.

Anyway we will need to replace BLine point with something. I don't
like "Spline Point" (I assume that "BLine" replaced to "Spline" here).
Because Point is looks like a point on the Spline (x,y), not a set of
elements. "Spline Item" is better but still clumsy. Let's look at the
illustration (what we have now) -
http://img254.imageshack.us/img254/982/20120522001.png

It's obvious that "Bline Point" type is referenced as "Vertex"
everywhere. Except one inconsistency - where "vector" type is called
"Vertex" too for some reason.

My proposal:
"Bline Point" -> "Vertex" (as set of elements)
"Vertex" (as sub-parameter of BLine Point) -> "Point"

See illustration with changes:
http://img543.imageshack.us/img543/9751/201205220012.png

So, my preferences:

Ducks -> Handles
Cpoint -> Color Stop
Encapsulate -> Group
Paste Canvas Layer -> Group Layer
Group -> Set
Bline -> Spline or Shape or Curve
Params Panel -> Parameters Panel
Curves panel -> Graphs panel (not "Graph Panel")
"Bline Point" -> "Vertex" (as set of elements)
"Vertex" (as sub-parameter of BLine Point) -> "Point"

Did I missed something? ^__^

2012/5/22 Yu Chen <jcomee <at> gmail.com>:
> The new _group
> layer_  and _group tool_ can take the folder icon used by current group
> panel, as we are trying to introduce _group concept_ in other bitmap based
> softwares. folder metaphor is used in Photoshop, AnimePro etc...

We are not introducing new concepts, we just introducing new
terminology. And that's not lead to any changes in the way how Synfig
behave.

Yes, the "Tag" icon used for metadata should be replaced too...

== Icons to rework ==
"Encapsulate" icon →"Group" icon
"Canvas green icon"→"Group layer icon"
"Select all child layers"
"Canvas" parameter
"Set"
"Add layers to set"
"Remove layers from set"
"Metadata Panel"

2012/5/22 Yu Chen <jcomee <at> gmail.com>:
> I can take some tasks too, but I can't promise too much since my poor
> english :)
My English is poor as well. ^__^ All we need is to ensure that we have
consistent (new) terminology everywhere in documentation. We don't
plan to do a huge rewrite - that will be a different challenge for the
future.

So, for documentation reorganization we have following people willing to help:
- Me
- Timothée Giet
- Yu Chen

The sequence of our actions should be:
1. Make code changes
2. Make new icons
3. Change documentation

2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez <at> yahoo.es>:
> Regarding to renaming implementation process I think that we should do it in
> one shot but without hurry up due to a new release. I don't plan to do a
> release soon. Unless someone come with some substantial commits and it
> deserves a release, the next release is planned with the new Cairo
> implementation as main change so it will take a while at the moment.

I think that we should do changes and release with new terminology
even if we have no new features.
This will indicate a new step - reworked terminology. In fact I DO
prefer to release WITHOUT new features, because we should do release
and documentation change in sync and quick - and that's a lot of work.
If we will have new features - the it will be too much for me to
handle at one shot. Sorry.

K.

--

-- 
http://morevnaproject.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Carlos Lopez Gonzalez | 22 May 18:21 2012
Picon
Picon

Re: Hi Synfig devs

I would like to invite to fill the chart I've made. All you have write rights I think.
I won't start any code string substitution until the chart is filled and agreed :-P
https://docs.google.com/spreadsheet/ccc?key=0Ah8g_H3f7qpZdDR1N0piUThqZ0pySjh3eERzMjBDQVE

Zelgadis wrote:
--------------------
2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez-mRCrAkd8dF0@public.gmane.org>:
> ...if we rename Duck to
> Control point we should say: "Then the user should select all the Curve
> point's Control points" instead of "Then the user selects all the BLine
> point's Ducks.".
> ...
> BLine point: Derived from above. We currently talk about BLine point's
> tangent duck as something easy to find and understand. Translated it would
> be: "Curve point's tangent Control point" too many points in my opinion.
> "Spline Item tangent's handle" sounds better to me. Well, everything sounds
> strange to me now! ^__^''

Let's don't make things too complicated. I don't remember such strange
phrases like "Then the user selects all the BLine point's Ducks." in
documentation. Even if we have such ones, let's avoid them. Keep it
simple: "User should select a vertex together with its tangents". Or:
"User should select a vertex together with its tangent and width
handles". It's just a matter of good writing style. ^__^

In fact BLinePoint is a kind of internal concept that visible to user
only as the parameter type. He needs that definition only in
export/linking operation to distinguish vertex (as BLine Point
element) from the whole Bline point. We don't have "BLine Points" list
- it's called "Vertices". So we shouldn't use the BlinePoint in user
documentation very much.

--------------------

I have to disagree on that. For bones BLine Point concept is very important
 because it will appear converted to a new type: Bone Influence type. 
The BLine point (vertex and tangents together) will be under a new type that
 has the influence of bones. Also, vertex individually can be bone influenced 
alone. So for good or bad, the concept of BLine point should be defined and documented.  


Zelgadis wrote:
-----------------------------
Anyway we will need to replace BLine point with something. I don't
like "Spline Point" (I assume that "BLine" replaced to "Spline" here).
Because Point is looks like a point on the Spline (x,y), not a set of
elements. "Spline Item" is better but still clumsy. Let's look at the
illustration (what we have now) -
http://img254.imageshack.us/img254/982/20120522001.png

It's obvious that "Bline Point" type is referenced as "Vertex"
everywhere. Except one inconsistency - where "vector" type is called
"Vertex" too for some reason.

My proposal:
"Bline Point" -> "Vertex" (as set of elements)
"Vertex" (as sub-parameter of BLine Point) -> "Point"

See illustration with changes:
http://img543.imageshack.us/img543/9751/201205220012.png
-------------------------

Vertex sounds ok but, what about the confusion with the Polygon vertices?
To use Vertex to a Polygon is perfect by dictionary vertex definition but since the 
Spline, BLine or whatever we call it is something special, we need to use a special 
word. 

Point is ok as sub parameter of blinepoint or vertex or whatever. Point is exactly that: a (x,y) location.


Zelgadis wrote:
-----------------------------
2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez-mRCrAkd8dF0@public.gmane.org>:
> Regarding to renaming implementation process I think that we should do it in
> one shot but without hurry up due to a new release. I don't plan to do a
> release soon. Unless someone come with some substantial commits and it
> deserves a release, the next release is planned with the new Cairo
> implementation as main change so it will take a while at the moment.

I think that we should do changes and release with new terminology
even if we have no new features.
This will indicate a new step - reworked terminology. In fact I DO
prefer to release WITHOUT new features, because we should do release
and documentation change in sync and quick - and that's a lot of work.
If we will have new features - the it will be too much for me to
handle at one shot. Sorry.
---------------------

It is ok. Now I understand.
Cheers
Carlos
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Timothée Giet | 22 May 22:34 2012
Picon

Re: Hi Synfig devs



2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez-mRCrAkd8dF0@public.gmane.org>
I would like to invite to fill the chart I've made. All you have write rights I think.
I won't start any code string substitution until the chart is filled and agreed :-P
https://docs.google.com/spreadsheet/ccc?key=0Ah8g_H3f7qpZdDR1N0piUThqZ0pySjh3eERzMjBDQVE



Thank you Carlos for this spreadsheet, very good idea.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@...
https://lists.sourceforge.net/lists/listinfo/synfig-devl
Zelgadis | 23 May 06:37 2012
Picon

Re: Hi Synfig devs

2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez@...>:
> I would like to invite to fill the chart I've made. All you have write
> rights I think.
> I won't start any code string substitution until the chart is filled and
> agreed :-P
> https://docs.google.com/spreadsheet/ccc?key=0Ah8g_H3f7qpZdDR1N0piUThqZ0pySjh3eERzMjBDQVE

Nice! Very cool! ^__^

> Zelgadis wrote:
> --------------------
>
> 2012/5/22 Carlos Lopez Gonzalez <carloslopezgonzalez@...>:
>> ...if we rename Duck to
>> Control point we should say: "Then the user should select all the Curve
>> point's Control points" instead of "Then the user selects all the BLine
>> point's Ducks.".
>> ...
>> BLine point: Derived from above. We currently talk about BLine point's
>> tangent duck as something easy to find and understand. Translated it would
>> be: "Curve point's tangent Control point" too many points in my opinion.
>> "Spline Item tangent's handle" sounds better to me. Well, everything
>> sounds
>> strange to me now! ^__^''
>
> Let's don't make things too complicated. I don't remember such strange
> phrases like "Then the user selects all the BLine point's Ducks." in
> documentation. Even if we have such ones, let's avoid them. Keep it
> simple: "User should select a vertex together with its tangents". Or:
> "User should select a vertex together with its tangent and width
> handles". It's just a matter of good writing style. ^__^
>
> In fact BLinePoint is a kind of internal concept that visible to user
> only as the parameter type. He needs that definition only in
> export/linking operation to distinguish vertex (as BLine Point
> element) from the whole Bline point. We don't have "BLine Points" list
> - it's called "Vertices". So we shouldn't use the BlinePoint in user
> documentation very much.
>
> --------------------
>
> I have to disagree on that. For bones BLine Point concept is very important
>  because it will appear converted to a new type: Bone Influence type.
> The BLine point (vertex and tangents together) will be under a new type that
>  has the influence of bones. Also, vertex individually can be bone
> influenced
> alone. So for good or bad, the concept of BLine point should be defined and
> documented.

"we shouldn't use the BlinePoint in user documentation very much" = we
WILL use it, but not much. ^__^

> Zelgadis wrote:
> -----------------------------
> Anyway we will need to replace BLine point with something. I don't
> like "Spline Point" (I assume that "BLine" replaced to "Spline" here).
> Because Point is looks like a point on the Spline (x,y), not a set of
> elements. "Spline Item" is better but still clumsy. Let's look at the
> illustration (what we have now) -
> http://img254.imageshack.us/img254/982/20120522001.png
>
> It's obvious that "Bline Point" type is referenced as "Vertex"
> everywhere. Except one inconsistency - where "vector" type is called
> "Vertex" too for some reason.
>
> My proposal:
> "Bline Point" -> "Vertex" (as set of elements)
> "Vertex" (as sub-parameter of BLine Point) -> "Point"
>
> See illustration with changes:
> http://img543.imageshack.us/img543/9751/201205220012.png
> -------------------------
>
> Vertex sounds ok but, what about the confusion with the Polygon vertices?
> To use Vertex to a Polygon is perfect by dictionary vertex definition but
> since the
> Spline, BLine or whatever we call it is something special, we need to use a
> special
> word.

>From user point of view Polygon Vertex is simplified case of Spline Vertex.

> Point is ok as sub parameter of blinepoint or vertex or whatever. Point is
> exactly that: a (x,y) location.

I also have another idea - we can use "Origin" instead of "Point".
I.e. "Origin of Vertex/Spline Item" like "Origin of Group (PasteCanvas) layer".
When referencing ducks it's ok  to use "Vertex handle" instead of
"Vertex Origin". In fact, even in current documentation we use simple
constructions:
* If you want to remove a vertex, right click on it and select "Delete Vertex".
* If you want to manipulate the vertices after you have created the
layers, it is very easy to do so.
(http://wiki.synfig.org/wiki/Doc:Creating_Shapes)

BTW, try to replace"vertex" with "spline item" in sentences above and
you'll get a bit clumsy results.

Well, after reading the documentation I still come to conclusion that
"control point" is still better than "handle". Let's see by example
from the same page:
* Despite the fact that they are two separate layers, their vertices
parameter has already been linked — so you can select either one and
move its ducks around and the other one will also change.
* You do this by selecting the outline layer and tweaking with the width ducks.
* If brown ducks are in your way, you can hide them by clicking the
"Toggle vertex ducks" button at the top of the canvas window (the
second one from the left).
Replacing "ducks" with "control points" make it sound better than
"handles" for my taste.

K.

--

-- 
http://morevnaproject.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Gmane