https://www.wiki.synfig.org/api.php?action=feedcontributions&user=Ciaran&feedformat=atomSynfig Studio :: Documentation - User contributions [en]2024-03-28T23:35:42ZUser contributionsMediaWiki 1.26.3https://www.wiki.synfig.org/index.php?title=User:Ciaran&diff=20010User:Ciaran2015-01-10T18:56:00Z<p>Ciaran: /* Simplifying synfig's wiki syntax */ True :-) But I'm hoping my comments will be useful in the long-term. I've managed a few wikis and my experience is: ::* Unfortunately, there is no easy/clean way to manage multiple languages ::* MediaWiki is the be</p>
<hr />
<div>Hi,<br />
<br />
I'm Ciarán O'Riordan. I have very little experience with Synfig.<br />
<br />
I've a homepage here: http://ciaran.compsoc.com/<br />
<br />
==Notes to self==<br />
<br />
===Simplifying synfig's wiki syntax===<br />
<br />
The below pages were made when trying to understand how [[template:L]] works. However, [[template:title]] has no effect on my test pages (I've also see this problem in the main namespace, so it's not just that it doesn't work in the userpage namespace), so this test was cancelled. (I reported this as a bug here: [[Talk:Main_Page#template:title_doesn.27t_change_the_title]])<br />
<br />
* [[User:Ciaran/sandbox]]<br />
* [[User:Ciaran/test2/fr]]<br />
* [[User:Ciaran/test2]]<br />
<br />
[[Template:L]] can be seen working on, for example, the [[Main Page]]. In the English version, there is a link to <nowiki>{{l|User Documentation}}</nowiki> and that is displayed as "User Documentation". In the French version ([[Main Page/fr]]) the link is also in English (<nowiki>{{l|User Documentation}}</nowiki>) but it is displayed as "Documentation Utilisateur". That page ([[User Documentation/fr]]) has <nowiki>{{Title|Documentation Utilisateur}}</nowiki>, so that ''might'' be where the translation is coming from. But, strangely, the title displayed for that page is "Glossaire"!<br />
<br />
:- I think until the wiki is not safe of errors/warning like this one ''"Warning: Cannot modify header information - headers already sent by (output started at /data/web/73/20/2d/wiki.synfig.org/htdocs/wiki/extensions/DynamicPageList/DPLMain.php:2549) in /data/web/73/20/2d/wiki.synfig.org/htdocs/wiki/includes/WebResponse.php on line 38"'' it could be difficult to expect rational things ;-) --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:03, 9 January 2015 (UTC)<br />
<br />
::True :-) But I'm hoping my comments will be useful in the long-term. I've managed a few wikis and my experience is:<br />
::* Unfortunately, there is no easy/clean way to manage multiple languages<br />
::* MediaWiki is the best engine<br />
::* Keep it simple - adding a layer of abstraction (like template:L) is ''sometimes'' necessary (rarely), but it ''always'' causes problems in the short and long term, so it should be avoided unless there is a really strong reason. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:56, 10 January 2015 (UTC)<br />
<br />
Current thoughts: [[Template:L]] contains just "<nowiki>{{#link:{{{1}}}|{{{2|}}}}}</nowiki>". So either "#link" recognises [[template:title]] or there is something being done by an extension such as MultilanguageSupport.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran&diff=20005User:Ciaran2015-01-06T11:17:02Z<p>Ciaran: /* Simplifying synfig's wiki syntax */ (I've also see this problem in the main namespace, so it's not just that it doesn't work in the userpage namespace)</p>
<hr />
<div>Hi,<br />
<br />
I'm Ciarán O'Riordan. I have very little experience with Synfig.<br />
<br />
I've a homepage here: http://ciaran.compsoc.com/<br />
<br />
==Notes to self==<br />
<br />
===Simplifying synfig's wiki syntax===<br />
<br />
The below pages were made when trying to understand how [[template:L]] works. However, [[template:title]] has no effect on my test pages (I've also see this problem in the main namespace, so it's not just that it doesn't work in the userpage namespace), so this test was cancelled. (I reported this as a bug here: [[Talk:Main_Page#template:title_doesn.27t_change_the_title]])<br />
<br />
* [[User:Ciaran/sandbox]]<br />
* [[User:Ciaran/test2/fr]]<br />
* [[User:Ciaran/test2]]<br />
<br />
[[Template:L]] can be seen working on, for example, the [[Main Page]]. In the English version, there is a link to <nowiki>{{l|User Documentation}}</nowiki> and that is displayed as "User Documentation". In the French version ([[Main Page/fr]]) the link is also in English (<nowiki>{{l|User Documentation}}</nowiki>) but it is displayed as "Documentation Utilisateur". That page ([[User Documentation/fr]]) has <nowiki>{{Title|Documentation Utilisateur}}</nowiki>, so that ''might'' be where the translation is coming from. But, strangely, the title displayed for that page is "Glossaire"!<br />
<br />
Current thoughts: [[Template:L]] contains just "<nowiki>{{#link:{{{1}}}|{{{2|}}}}}</nowiki>". So either "#link" recognises [[template:title]] or there is something being done by an extension such as MultilanguageSupport.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran&diff=20004User:Ciaran2015-01-06T11:15:02Z<p>Ciaran: /* Simplifying synfig's wiki syntax */ (I reported this as a bug here: Talk:Main_Page#template:title_doesn.27t_change_the_title)</p>
<hr />
<div>Hi,<br />
<br />
I'm Ciarán O'Riordan. I have very little experience with Synfig.<br />
<br />
I've a homepage here: http://ciaran.compsoc.com/<br />
<br />
==Notes to self==<br />
<br />
===Simplifying synfig's wiki syntax===<br />
<br />
The below pages were made when trying to understand how [[template:L]] works. However, [[template:title]] has no effect on my test pages (maybe it only works in the main namespace, not in the userpage namespace), so this test was cancelled. (I reported this as a bug here: [[Talk:Main_Page#template:title_doesn.27t_change_the_title]])<br />
<br />
* [[User:Ciaran/sandbox]]<br />
* [[User:Ciaran/test2/fr]]<br />
* [[User:Ciaran/test2]]<br />
<br />
[[Template:L]] can be seen working on, for example, the [[Main Page]]. In the English version, there is a link to <nowiki>{{l|User Documentation}}</nowiki> and that is displayed as "User Documentation". In the French version ([[Main Page/fr]]) the link is also in English (<nowiki>{{l|User Documentation}}</nowiki>) but it is displayed as "Documentation Utilisateur". That page ([[User Documentation/fr]]) has <nowiki>{{Title|Documentation Utilisateur}}</nowiki>, so that ''might'' be where the translation is coming from. But, strangely, the title displayed for that page is "Glossaire"!<br />
<br />
Current thoughts: [[Template:L]] contains just "<nowiki>{{#link:{{{1}}}|{{{2|}}}}}</nowiki>". So either "#link" recognises [[template:title]] or there is something being done by an extension such as MultilanguageSupport.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=20003Talk:Main Page2015-01-06T11:12:43Z<p>Ciaran: /* template:title doesn't change the title */ new section</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
::::::Hacking MediaWiki will take a full day or two, plus another day later for bug fixing, and then you'd have to maintain the patch for all future upgrades. That's a lot of work if you're busy.<br />
::::::There are lots of ways to logically separate things. You could include a template in all dev articles causing them to be in one category and to display "this is a dev article" at the top.<br />
::::::I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:32, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)<br />
<br />
== I've converted the links back to [[template:L]] ==<br />
<br />
For the pages that I edited, I've gone back now and converted all the normal links to template:L links.<br />
<br />
It's your wiki, so I'll go with your decision, but I think this is shooting yourself in the foot if you want to attract new wiki contributors.<br />
<br />
I can understand using [[template:title]]. It's only used once per page, and it only has to be written by the first person who makes the page, so it's almost invisible to other people editing the wiki. Changing a page's title is not normal, so translators might need to be reminded to do this.<br />
<br />
[[Template:L]] is different because some pages use it dozens of times, and it is mixed into the page's content, so anyone who edits the page might have to use template:L, so they see this meta-syntax instead of normal MediaWiki syntax. This might make new contributors less likely to contribute. And, unlike [[template:title]], I can't see any good reason for template:L.<br />
<br />
Other suggestion: if you are going to replace MediaWiki syntax with your own custom meta-syntax, then it should be documented somewhere that new contributors will see.<br />
<br />
I was going to do that myself, by adding links from the template pages to the [[Meta:Template_Style_And_Syntax|documentation]], but I can't because those template pages are locked. Is there a real reason for them to be locked? Have spambots or vandals ever abused your templates? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 12:09, 2 January 2015 (UTC)<br />
<br />
P.S. [[template:L]] doesn't work fully for file links. Arguments like "left" and accompanying text get ignored. For example:<br />
<br />
<nowiki>{{l|File:Track-Curve-tutorial-Follow-bline.gif|frame|left|Extract of Follow-bline as animated gif / 3s - 210ko / ffmpeg -i + gimp resize/export}}</nowiki><br />
<br />
Output:<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19989#Introduction Here it is with template:L] - note that it's not on the left and the text isn't displayed<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19953#Introduction Here it is with normal MediaWiki syntax]<br />
<br />
This can be fixed by either:<br />
* I can change the links from template:L links back to normal links (and [[Meta:Template_Style_And_Syntax#Links|the documentation]] should be updated to tell people not to use template:L for internal file links); or<br />
* You can fix template:L (This might be easy: where you currently have 1 and 2, maybe you just need to add 3, 4, 5 and 6)<br />
<br />
. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 13:57, 2 January 2015 (UTC)<br />
<br />
== template:title doesn't change the title ==<br />
<br />
If I understand correctly, [[template:title]] should change the title displayed at the top of the page, but [[User Documentation/fr]] has <nowiki>{{Title|Documentation Utilisateur}}</nowiki> at the top and yet the title displayed at the top of the page is "Glossaire".<br />
<br />
I made some test pages and found the same problem:<br />
<br />
{| style="border:1px solid silver;"<br />
|- style="background-color:#eee;"<br />
! style="border:1px solid silver;" | page<br />
! style="border:1px solid silver;" | template:title<br />
! style="border:1px solid silver;" | title displayed<br />
|-<br />
| [[User:Ciaran/sandbox]] || <nowiki>{{Title|sandbox}}</nowiki> || User:Ciaran/sandbox<br />
|-<br />
| [[User:Ciaran/test2/fr]] || <nowiki>{{title|essai}}</nowiki> || User:Ciaran/test2/fr<br />
|-<br />
| [[User:Ciaran/test2]] || <nowiki>{{title|test2}}</nowiki> || User:Ciaran/test2<br />
|}<br />
<br />
I will be busy for the next while, so I probably won't leave any more comments. I hope my bug reports and suggestions were useful. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 11:12, 6 January 2015 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran&diff=20002User:Ciaran2015-01-06T10:55:25Z<p>Ciaran: /* Simplifying synfig's wiki syntax */ Current thoughts:</p>
<hr />
<div>Hi,<br />
<br />
I'm Ciarán O'Riordan. I have very little experience with Synfig.<br />
<br />
I've a homepage here: http://ciaran.compsoc.com/<br />
<br />
==Notes to self==<br />
<br />
===Simplifying synfig's wiki syntax===<br />
<br />
The below pages were made when trying to understand how [[template:L]] works. However, [[template:title]] has no effect on my test pages (maybe it only works in the main namespace, not in the userpage namespace), so this test was cancelled.<br />
<br />
* [[User:Ciaran/sandbox]]<br />
* [[User:Ciaran/test2/fr]]<br />
* [[User:Ciaran/test2]]<br />
<br />
[[Template:L]] can be seen working on, for example, the [[Main Page]]. In the English version, there is a link to <nowiki>{{l|User Documentation}}</nowiki> and that is displayed as "User Documentation". In the French version ([[Main Page/fr]]) the link is also in English (<nowiki>{{l|User Documentation}}</nowiki>) but it is displayed as "Documentation Utilisateur". That page ([[User Documentation/fr]]) has <nowiki>{{Title|Documentation Utilisateur}}</nowiki>, so that ''might'' be where the translation is coming from. But, strangely, the title displayed for that page is "Glossaire"!<br />
<br />
Current thoughts: [[Template:L]] contains just "<nowiki>{{#link:{{{1}}}|{{{2|}}}}}</nowiki>". So either "#link" recognises [[template:title]] or there is something being done by an extension such as MultilanguageSupport.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran&diff=20001User:Ciaran2015-01-06T10:44:20Z<p>Ciaran: Notes to self</p>
<hr />
<div>Hi,<br />
<br />
I'm Ciarán O'Riordan. I have very little experience with Synfig.<br />
<br />
I've a homepage here: http://ciaran.compsoc.com/<br />
<br />
==Notes to self==<br />
<br />
===Simplifying synfig's wiki syntax===<br />
<br />
The below pages were made when trying to understand how [[template:L]] works and what it does. However, [[template:title]] has no effect on my test pages (maybe it only works in the main namespace, not in the userpage namespace), so this test is cancelled.<br />
<br />
* [[User:Ciaran/sandbox]]<br />
* [[User:Ciaran/test2/fr]]<br />
* [[User:Ciaran/test2]]</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran/test2/fr&diff=20000User:Ciaran/test2/fr2015-01-06T10:40:22Z<p>Ciaran: {{title|essai}}</p>
<hr />
<div>{{title|essai}}<br />
<br />
<br />
This test is in French. {{l|User:Ciaran/sandbox}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran/test2/fr&diff=19999User:Ciaran/test2/fr2015-01-06T10:40:10Z<p>Ciaran: {{essai}} This test is in French. {{l|User:Ciaran/sandbox}}.</p>
<hr />
<div>{{essai}}<br />
<br />
<br />
This test is in French. {{l|User:Ciaran/sandbox}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran/test2&diff=19998User:Ciaran/test22015-01-06T10:38:30Z<p>Ciaran: {{title|test2}} Also a test. {{l|User:Ciaran/sandbox}}.</p>
<hr />
<div>{{title|test2}}<br />
<br />
Also a test. {{l|User:Ciaran/sandbox}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran/sandbox&diff=19997User:Ciaran/sandbox2015-01-06T10:37:09Z<p>Ciaran: fix link</p>
<hr />
<div>{{Title|sandbox}}<br />
<br />
<br />
This is a test. {{l|User:Ciaran/test2}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User:Ciaran/sandbox&diff=19996User:Ciaran/sandbox2015-01-06T10:36:49Z<p>Ciaran: {{Title|sandbox}} This is a test. {{l|test2}}.</p>
<hr />
<div>{{Title|sandbox}}<br />
<br />
<br />
This is a test. {{l|test2}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19992Talk:Main Page2015-01-02T14:11:18Z<p>Ciaran: /* I've converted the links back to template:L */ clearer</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
::::::Hacking MediaWiki will take a full day or two, plus another day later for bug fixing, and then you'd have to maintain the patch for all future upgrades. That's a lot of work if you're busy.<br />
::::::There are lots of ways to logically separate things. You could include a template in all dev articles causing them to be in one category and to display "this is a dev article" at the top.<br />
::::::I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:32, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)<br />
<br />
== I've converted the links back to [[template:L]] ==<br />
<br />
For the pages that I edited, I've gone back now and converted all the normal links to template:L links.<br />
<br />
It's your wiki, so I'll go with your decision, but I think this is shooting yourself in the foot if you want to attract new wiki contributors.<br />
<br />
I can understand using [[template:title]]. It's only used once per page, and it only has to be written by the first person who makes the page, so it's almost invisible to other people editing the wiki. Changing a page's title is not normal, so translators might need to be reminded to do this.<br />
<br />
[[Template:L]] is different because some pages use it dozens of times, and it is mixed into the page's content, so anyone who edits the page might have to use template:L, so they see this meta-syntax instead of normal MediaWiki syntax. This might make new contributors less likely to contribute. And, unlike [[template:title]], I can't see any good reason for template:L.<br />
<br />
Other suggestion: if you are going to replace MediaWiki syntax with your own custom meta-syntax, then it should be documented somewhere that new contributors will see.<br />
<br />
I was going to do that myself, by adding links from the template pages to the [[Meta:Template_Style_And_Syntax|documentation]], but I can't because those template pages are locked. Is there a real reason for them to be locked? Have spambots or vandals ever abused your templates? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 12:09, 2 January 2015 (UTC)<br />
<br />
P.S. [[template:L]] doesn't work fully for file links. Arguments like "left" and accompanying text get ignored. For example:<br />
<br />
<nowiki>{{l|File:Track-Curve-tutorial-Follow-bline.gif|frame|left|Extract of Follow-bline as animated gif / 3s - 210ko / ffmpeg -i + gimp resize/export}}</nowiki><br />
<br />
Output:<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19989#Introduction Here it is with template:L] - note that it's not on the left and the text isn't displayed<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19953#Introduction Here it is with normal MediaWiki syntax]<br />
<br />
This can be fixed by either:<br />
* I can change the links from template:L links back to normal links (and [[Meta:Template_Style_And_Syntax#Links|the documentation]] should be updated to tell people not to use template:L for internal file links); or<br />
* You can fix template:L (This might be easy: where you currently have 1 and 2, maybe you just need to add 3, 4, 5 and 6)<br />
<br />
. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 13:57, 2 January 2015 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19991Talk:Main Page2015-01-02T14:06:08Z<p>Ciaran: /* I've converted the links back to template:L */ shorten slightly</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
::::::Hacking MediaWiki will take a full day or two, plus another day later for bug fixing, and then you'd have to maintain the patch for all future upgrades. That's a lot of work if you're busy.<br />
::::::There are lots of ways to logically separate things. You could include a template in all dev articles causing them to be in one category and to display "this is a dev article" at the top.<br />
::::::I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:32, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)<br />
<br />
== I've converted the links back to [[template:L]] ==<br />
<br />
For the pages that I edited, I've gone back now and converted all the normal links to template:L links.<br />
<br />
It's your wiki, so I'll go with your decision, but I think this is shooting yourself in the foot if you want to attract new wiki contributors.<br />
<br />
I can understand using [[template:title]]. It's only used once per page, and it only has to be written by the first person who makes the page, so it's almost invisible to other people editing the wiki. Changing a page's title is not normal, so translators might need to be reminded to do this.<br />
<br />
[[Template:L]] is different because some pages use it dozens of times, and it is mixed into the page's content, so anyone who edits the page might have to use template:L, so they see this meta-syntax instead of normal MediaWiki syntax. This might make new contributors less likely to contribute. And, unlike [[template:title]], I can't see any good reason for template:L.<br />
<br />
Other suggestion: if you are going to replace MediaWiki syntax with your own custom meta-syntax, then it should be documented somewhere that new contributors will see.<br />
<br />
I was going to do that myself, by adding links from the template pages to the [[Meta:Template_Style_And_Syntax|documentation]], but I can't because those template pages are locked. Is there a real reason for them to be locked? Have spambots or vandals ever abused your templates? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 12:09, 2 January 2015 (UTC)<br />
<br />
P.S. [[template:L]] doesn't work fully for file links. Arguments like "left" and accompanying text get ignored. For example:<br />
<br />
<nowiki>{{l|File:Track-Curve-tutorial-Follow-bline.gif|frame|left|Extract of Follow-bline as animated gif / 3s - 210ko / ffmpeg -i + gimp resize/export}}</nowiki><br />
<br />
Output:<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19989#Introduction Here it is with template:L] - note that it's not on the left and the text isn't displayed)<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19953#Introduction Here it is with normal MediaWiki syntax]<br />
<br />
If you're going to fix this by changing template:L, then I won't change those pages. Or if template:L won't be changed, then I'll change those pages back to using normal MediaWiki link syntax. (And [[Meta:Template_Style_And_Syntax#Links|the documentation]] should be updated to tell people not to use template:L for internal file links.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 13:57, 2 January 2015 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19990Talk:Main Page2015-01-02T13:57:28Z<p>Ciaran: /* I've converted the links back to template:L */ P.S. template:L doesn't work fully for file links. Arguments like "left" and accompanying text get ignored.</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
::::::Hacking MediaWiki will take a full day or two, plus another day later for bug fixing, and then you'd have to maintain the patch for all future upgrades. That's a lot of work if you're busy.<br />
::::::There are lots of ways to logically separate things. You could include a template in all dev articles causing them to be in one category and to display "this is a dev article" at the top.<br />
::::::I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:32, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)<br />
<br />
== I've converted the links back to [[template:L]] ==<br />
<br />
For the pages that I edited, I've gone back now and converted all the normal links to template:L links.<br />
<br />
It's your wiki, so I'll go with your decision, but I think this is shooting yourself in the foot if you want to attract new wiki contributors.<br />
<br />
I can understand using [[template:title]]. It's only used once per page, and it only has to be written by the first person who makes the page, so it's almost invisible to other people editing the wiki. Its purpose is to remind translators to translate the title. Changing a page's title is not normal, so translators might need to be reminded to do this.<br />
<br />
[[Template:L]] is different because some pages use it dozens of times, and it is mixed into the page's content, so anyone who edits the page might have to use template:L, so they see this meta-syntax instead of normal MediaWiki syntax. This might make new contributors less likely to contribute. And, unlike [[template:title]], I can't see any good reason for template:L.<br />
<br />
Other suggestion: if you are going to replace MediaWiki syntax with your own custom meta-syntax, then it should be documented somewhere that new contributors will see.<br />
<br />
I was going to do that myself, by adding links from the template pages to the [[Meta:Template_Style_And_Syntax|documentation]], but I can't because those template pages are locked. Is there a real reason for them to be locked? Have spambots or vandals ever abused your templates? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 12:09, 2 January 2015 (UTC)<br />
<br />
P.S. [[template:L]] doesn't work fully for file links. Arguments like "left" and accompanying text get ignored. For example:<br />
<br />
<nowiki>{{l|File:Track-Curve-tutorial-Follow-bline.gif|frame|left|Extract of Follow-bline as animated gif / 3s - 210ko / ffmpeg -i + gimp resize/export}}</nowiki><br />
<br />
Gives:<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19989#Introduction Here it is with template:L - note that it's not on the left and the text isn't displayed)]<br />
<br />
But:<br />
<br />
* [http://wiki.synfig.org/wiki/index.php?title=Tracking_Curves&oldid=19953#Introduction Here it is with normal MediaWiki syntax]<br />
<br />
If you're going to fix this by changing template:L, then I'll leave the pages as-is. Or if template:L shouldn't be used for file links, then I'll change them back to using normal MediaWiki link syntax. (And [[Meta:Template_Style_And_Syntax#Links|the documentation]] should be updated to tell people not to use template:L for file links.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 13:57, 2 January 2015 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Tracking_Curves&diff=19989Tracking Curves2015-01-02T13:45:38Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Tracking Curves}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
<br />
:Note: There is a newer tutorial for this topic at {{l|Doc:Following a Spline}}, however, some info from this tutorial such as link/export hasn't yet been added to the new tutorial. There is also another {{l|Following a BLine (the very old way)|''very'' out-of-date tutorial}} for synfig 0.61.08.<br />
<br />
== Introduction ==<br />
{{l|File:Track-Curve-tutorial-Follow-bline.gif|frame|left|Extract of Follow-bline as animated gif / 3s - 210ko / ffmpeg -i + gimp resize/export}}<br />
[http://uk.youtube.com/watch?v=wJ7C-FcxAy0 YouTube] | <br />
{{l|Media:Follow-bline.sifz|follow-bline.sifz}} | [http://dooglus.rincevent.net/synfig/follow-bline.avi follow-bline.avi]<br />
<br />
<br />
The above example links show an animation in which a layer follows a moving curve, and rotates to follow the curve as it moves.<br />
<br />
How was that achieved? It's currently quite complicated to set up an arrangement like this in Synfig Studio, so I'll describe here how it works.<br />
<br />
== Discussion ==<br />
<br />
If you download the .sifz file and load it into Synfig Studio, it really isn't easy to see how the effect is achieved.<br />
<br />
When this animation was created (in 2007), it was possible to make a layer track a curve with just 2 points, but not to get it to track a general curve.<br />
<br />
Since then, new {{l|Convert|conversion types}} called "{{l|Convert#Spline Vector|Spline Vector}}" and "{{l|Convert#Spline Tangent|Spline Tangent}}" have been added to Synfig, and so tracking a general {{Literal|Spline}} is now possible. See {{l|Doc:Following a Spline|this tutorial}} for an example.<br />
<br />
== Details ==<br />
<br />
=== Overview ===<br />
<br />
The animation lasts for 32 seconds and has 3 top-level layers. This is a very simple animation other than the two parts with links (below), which control the location of the moving blob and the shape of the white beam of light respectively. These two parts are described separately.<br />
<br />
The three top-level layers are as follows:<br />
<br />
<blockquote><br />
<br />
==== top-level layer 1: moving blob ====<br />
<br />
An {{l|Group|group}} of three layers. Its origin is {{l|Connect|connected}} to the {{l|Export|exported}} {{l|ValueNode}} "{{l|Tracking Curves#Moving Point|moving point}}". The three {{l|Layers|layers}} are:<br />
* direction of movement - The fuzzy white beam of light. This is a simple spline with a feather of 0.3 units to make it fuzzy. Its vertices are connected to the {{l|ValueNode}} called "{{l|Tracking Curves#Beam of Light|beam of light}}".<br />
* inner circle - The smaller yellow circle. Not animated at all.<br />
* outer circle - The larger red circle. Not animated at all.<br />
<br />
Note the technique here. I could have animated both of the two circles and the beam all separately, but it is much simpler to group them into a single Group layer and animate the position of that instead.<br />
<br />
==== top-level layer 2: line ====<br />
<br />
The moving curve which the object follows. It has {{l|Waypoints|waypoints}} at 0s, 16s, and 32s to make the line move. I {{l|Export|exported}} four of its animated {{l|ValueNode|ValueNodes}} so that I could use them later to define the curved segment that the blob should follow.<br />
<br />
The exported four {{l|ValueNode|ValueNodes}} are:<br />
* vertex1 - The position of the beginning of the curve<br />
* vertex2 - The position of the end of the curve<br />
* tangent1 - The tangent at the beginning of the curve<br />
* tangent2 - The tangent at the end of the curve<br />
<br />
The moving curve is an {{l|Outline Layer}}, created using the {{l|Spline Tool}}. It only has 2 vertices. Note that the {{l|Spline Tool}} creates layers which have lists of {{l|SplinePoints}} to define the shape of the layer, and that {{l|SplinePoints}} contain more than just vertices and tangents. {{l|SplinePoints}} also have parameters like split tangents', and {{Literal|width}}, which aren't relevant when creating a Segment, so I only exported the four {{l|ValueNode|ValueNodes}} that I needed to create the Segment.<br />
<br />
==== top-level layer 3: black background ====<br />
<br />
A solid black background. Not animated at all.<br />
<br />
</blockquote><br />
<br />
=== Moving Point ===<br />
<br />
The "moving point" {{l|ValueNode}} represents the point on the moving spline where the circles are currently centered. It is an exported ValueNode of type "{{l|Convert#Segment Vertex|Segment Vertex}}". It has 2 components which determine the vertex that is used as its value:<br />
* segment - this uses the ValueNode called "{{l|Tracking Curves#Spline|spline}}"<br />
* amount - this uses the ValueNode called "{{l|Tracking Curves#Spline Parameter|spline parameter}}"<br />
<br />
=== Beam of Light ===<br />
<br />
The "beam of light" ValueNode is a two-point spline, with vertices as follows:<br />
* Vertex001 - This is the vertex at the center of the circle. It doesn't need to move, since the circles don't move. What moves is the "moving blob" layer, the {{l|Group|group}} layer which contains this line and the two circles. So this vertex has a constant position of (0,0)<br />
* Vertex002 - This is the other end of the fuzzy white beam. It was a width of 5 units to make the beam diverge. Its position is connected to the ValueNode called "{{l|Tracking Curves#Scaled Tangent|scaled tangent}}".<br />
<br />
=== Scaled Tangent ===<br />
<br />
The "scaled tangent" ValueNode is the offset vector from the center of the circles to the wide end of the beam of light.<br />
<br />
This offset needs to be a vector in a direction parallel to the tangent to the moving curve at the current point. This was achieved using the Scale convert type, with 2 sub parameters:<br />
* Link - This is the vector to scale. It is a vector representing the tangent to the moving curve at the current position of the circles, and so I called it "tangent". This is arrived at using the {{l|Convert#Segment Tangent|Segment Tangent}} conversion type, which has two sub-parameters:<br />
** Segment - this re-uses the ValueNode called "{{l|Tracking Curves#Spline|spline}}"<br />
** Amount - this re-uses the ValueNode called "{{l|Tracking Curves#Spline Parameter|spline parameter}}"<br />
* Scalar - This is the amount to scale it by. Spline curves have tangents which point from the start vertex towards the end vertex, along the curve. I want my beam of light to point in the direction of travel, which is sometimes towards the start of the curve and sometimes towards the end. To do this I needed to multiply the "tangent" ValueNode above by a number which would be negative when traveling towards the start of the curve. It just so happens that sin(angle+90) has exactly that property, and also has the benefit of making the beam get longer as the movement speeds up. So I called this ValueNode "(sin(angle+90))" and defined it as a "Sine" convert type, defined as value=Amplitude*sin(Angle):<br />
** Angle - This needs to be "Angle+90", so it's defined as a subtraction (Synfig has a 'subtract' convert type, but no add). value = LHS-RHS:<br />
*** LHS - The left hand side of the subtraction - this is connected to "{{l|Tracking Curves#Linearly Changing Angle|linearly changing angle}}"<br />
*** RHS - The right hand side of the subtraction. It's a constant -90.<br />
** Amplitude - This is a constant 0.4, which simply scales the length of the beam of light down to keep it mostly on the screen.<br />
<br />
=== Spline ===<br />
<br />
The "spline" ValueNode is a segment representing the curve to follow. It connects to the vertex1, vertex2, tangent1, and tangent2 ValueNodes, as exported from the '{{l|Tracking Curves#top-level layer 2: line|line}}' layer above.<br />
<br />
=== Spline Parameter ===<br />
<br />
The "Spline parameter" ValueNode is number ranging from 0 to 1, which indicates how far along the segment to go. 0 means "use vertex1" and 1 means "use vertex2".<br />
<br />
I want the point to travel along the curve [http://en.wikipedia.org/wiki/Sinusoidal sinusoidally], meaning it will travel fastest in the middle and slow to a momentary stop at either end. This makes the movement look smoother than using a linear movement.<br />
<br />
The sin() function returns a number between -1 and 1, and I want a value between 0 and 1, so I halve the sin() value, giving -0.5 to 0.5, then add 0.5 to it, giving 0 to 1.<br />
<br />
Consequently, this 'spline parameter' value is the result of a subtraction, LHS-RHS:<br />
* LHS - The left hand side of the subtraction. I called this ValueNode "((sin(angle))/2). This will range from -0.5 to 0.5, and is the result of the '{{l|Convert#Sine|sine}}' convert type, sin(Angle)*Amplitude:<br />
** Angle - This is connected to "{{l|Tracking Curves#Linearly Changing Angle|linearly changing angle}}"<br />
** Amplitude - This is used to scale the value. Since I want sin(Angle)/2, the value is a constant 0.5.<br />
* RHS - The right hand side of the subtraction. I wanted to add 0.5 to sin(angle)/2, but synfig only offers subtraction, so I subtracted -0.5 instead, which is the same. Thus, RHS is a constant Real ValueNode, with value -0.5<br />
<br />
=== Linearly Changing Angle ===<br />
<br />
The "linearly changing angle" ValueNode is the constantly changing angle that drives the whole animation. Whenever the angle increases by 360 degrees, the output of sin(Angle) does one complete cycle from 0 -> 1 -> 0 -> -1 -> 0. The angle changes linearly, using the Linear convert type, which has 2 parameters:<br />
* Rate - How many degrees per second to increase. In the animation this is set to a constant value of 45 degrees per second. This means that one complete cycle (from the center to the right end, to the left end, and back to the center) will take 360/45 = 8 seconds to complete. This gives us four complete cycles in the 32 second animation.<br />
* Offset - The value at the beginning of the animation (time = 0). Changing this to 90 for example will make the blob start at the right-hand end of the line. while changing it to 180 will make the blob start in the middle, but facing (and traveling) left.<br />
<br />
== Screen Shot ==<br />
<br />
This screen shot shows all the exported ValueNodes in the top right. Note that a few of them aren't necessary, such as the {{Literal|yellow}}, {{Literal|red}}, and {{Literal|width}} {{l|ValueNodes}}. Well, actually none of them are necessary - it's possible to do the whole animation without exporting anything at all. It would lead to a small amount of duplication, since both the position of the blob and the direction of the light beam are driven by the same angle. But mainly exporting is a way of naming the ValueNodes, which acts as a kind of documentation.<br />
<br />
In the {{l|Parameters_Panel|Parameters}} panel in the bottom left you can see some of the sub-parameters of the '{{l|Tracking Curves#Moving Point|moving point}}' ValueNode.<br />
<br />
<gallery caption="Track Curve screenshots" widths="500px" heights="600px" perrow="2"><br />
File:Track-curve-tutorial-screenshot1.png|{{l|Canvas}} window and {{l|Parameters_Panel|Parameters}} panel.<br />
File:Track-curve-tutorial-screenshot2.png|{{l|Library_Panel|Libray}} and {{l|Layers_Panel|Layers}} panels.<br />
</gallery></div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19988Talk:Main Page2015-01-02T12:17:29Z<p>Ciaran: /* I've converted the links back to template:L */ I was going to do that myself, by adding links from the template pages to the documentation, but I can't because those template pages are locked. Is that really necessar</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
::::::Hacking MediaWiki will take a full day or two, plus another day later for bug fixing, and then you'd have to maintain the patch for all future upgrades. That's a lot of work if you're busy.<br />
::::::There are lots of ways to logically separate things. You could include a template in all dev articles causing them to be in one category and to display "this is a dev article" at the top.<br />
::::::I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:32, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)<br />
<br />
== I've converted the links back to [[template:L]] ==<br />
<br />
For the pages that I edited, I've gone back now and converted all the normal links to template:L links.<br />
<br />
It's your wiki, so I'll go with your decision, but I think this is shooting yourself in the foot if you want to attract new wiki contributors.<br />
<br />
I can understand using [[template:title]]. It's only used once per page, and it only has to be written by the first person who makes the page, so it's almost invisible to other people editing the wiki. Its purpose is to remind translators to translate the title. Changing a page's title is not normal, so translators might need to be reminded to do this.<br />
<br />
[[Template:L]] is different because some pages use it dozens of times, and it is mixed into the page's content, so anyone who edits the page might have to use template:L, so they see this meta-syntax instead of normal MediaWiki syntax. This might make new contributors less likely to contribute. And, unlike [[template:title]], I can't see any good reason for template:L.<br />
<br />
Other suggestion: if you are going to replace MediaWiki syntax with your own custom meta-syntax, then it should be documented somewhere that new contributors will see.<br />
<br />
I was going to do that myself, by adding links from the template pages to the [[Meta:Template_Style_And_Syntax|documentation]], but I can't because those template pages are locked. Is there a real reason for them to be locked? Have spambots or vandals ever abused your templates? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 12:09, 2 January 2015 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19987Talk:Main Page2015-01-02T12:09:06Z<p>Ciaran: /* I've converted the links back to template:L */ new section</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
::::::Hacking MediaWiki will take a full day or two, plus another day later for bug fixing, and then you'd have to maintain the patch for all future upgrades. That's a lot of work if you're busy.<br />
::::::There are lots of ways to logically separate things. You could include a template in all dev articles causing them to be in one category and to display "this is a dev article" at the top.<br />
::::::I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:32, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)<br />
<br />
== I've converted the links back to [[template:L]] ==<br />
<br />
For the pages that I edited, I've gone back and converted all the normal links to template:L links.<br />
<br />
It's your wiki, so I'll go with your decision, but I think this is shooting yourself in the foot.<br />
<br />
I can understand using [[template:title]]. It's only used once per page, and it only has to be written by the first person who makes the page, so it's almost invisible to other people editing the wiki. Its purpose is to remind translators to translate the title. Changing a page's title is not normal, so translators might need to be reminded to do this.<br />
<br />
[[Template:L]] is different because some pages use it dozens of times, and it is mixed into the page's content, so anyone who edits the page might have to use template:L, so they see this meta-syntax instead of normal MediaWiki syntax. This might make new contributors less likely to contribute. And, unlike [[template:title]], I can't see any good reason for template:L.<br />
<br />
Other suggestion: if you are going to replace MediaWiki syntax with your own custom meta-syntax, then it should be documented somewhere that new contributors will see. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 12:09, 2 January 2015 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Main_Page&diff=19986Main Page2015-01-02T11:51:55Z<p>Ciaran: rm ":" from category links</p>
<hr />
<div><!-- Page info --><br />
{{Title|Synfig Wiki}}<br />
<!-- Page info end --><br />
<br />
Welcome to the Synfig wiki. This wiki is the main documentation for the [http://www.synfig.org/ Synfig Project], a 2D animation and design program. The wiki documentation is divided in three main sections: {{l|User Documentation}} (for the users of the animation program), {{l|Developer Documentation}} (for the people developing the code of the program) and {{l|Writer Documentation}} (for the people that wish to keep this wiki up to date).<br />
<br />
Below is a list of all the items for each category of documentation.<br />
<br />
* '''{{l|User Documentation}}'''<br />
** {{l|Category:Manual|Manual}}. The Manual is a step by step walkthrough of the main aspects of Synfig Studio and the workflow to do animations with it. A snapshot is available for offline viewing from http://www.mediafire.com/?ucindxh81z8uga5<br />
** {{l|Category:Tutorials|Tutorials}}. Each tutorial is an independent guide that illustrates how to proceed to achieve a particular task.<br />
** {{l|Category:Reference|Reference}}. This is an exhaustive list of all the individual aspects of Synfig (GUI and command line). Use it when you need details on a particular aspect of the program.<br />
** {{l|Category:Glossary|Glossary}}. Some parts of the documentation have Synfig-specific naming or concepts. Research them here.<br />
* '''{{l|Developer Documentation}}'''<br />
* '''{{l|Writer Documentation}}'''<br />
<br />
<br />
<br />
'''To all writers and translators'''<br />
<br />
Please read the hints at {{l|Writer Documentation}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=FAQ&diff=19985FAQ2015-01-02T11:49:23Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|FAQ}}<br />
<!-- Page info end --><br />
<br />
== General FAQs ==<br />
<br />
=== Who is synfigbot at the Synfig IRC channel? ===<br />
<br />
synfigbot is a bot that sits in the [http://www.synfig.org/cms/en/support/ Synfig IRC channel], not a human. It has some commands and can respond to some of the usual questions like: "What's the latest Synfig Studio version?" One of its funnier commands is to quote past funny comments from people at the IRC. To make it remember a quote, just type: !q. Please be nice with it, it is still learning. ;)<br />
<br />
=== Why are the CIA in the Synfig IRC channel? ===<br />
<br />
"CIA-28" and friends are bots that sit in the {{l|Contact|Synfig IRC channel}} and report whenever they detect a new commit in the subversion repository, giving the committer's name, revision number, and commit log message. The same information for recent commits can be found on [http://cia.vc/stats/project/synfig cia.vc]. [http://www.ohloh.net/projects/4832?p=Synfig ohloh.net] has similar pages of statistics.<br />
<br />
== FAQs relating to the current Synfig release ==<br />
<br />
Many issues are documented in the [http://www.synfig.org/issues/thebuggenie/synfig bug tracker] ([http://www.synfig.org/cms/en/news/new-bug-tracker/ new bug tracker annonce]) and on the {{l|download}} page.<br />
<br />
=== What is the status of the MacOS package? ===<br />
<br />
We provide Mac packages. See [http://www.synfig.org/cms/en/news/mac-osx-dmg-package/ here]<br />
<br />
<strike>Some people have [http://sf.net/support/tracker.php?aid=1686495 volunteered] to work on a pure MacOS X package for synfig, but there have not yet been any results. Currently options for using synfig on MacOS X include: {{l|Dev:Building On Mac OS X|building it yourself}}, using Homebrew as mentioned in [http://synfig.org/forums/viewtopic.php?f=13&t=2678 this forum post], {{l|Download#fink|installing packages from fink}} or installing Linux or Windows on your machine and using it there.</strike><br />
<br />
=== Is there any Flash/SWF support? ===<br />
<br />
Unfortunately not. Patches are welcome though. Please {{l|contact}} us to discuss your plans for adding SWF support so we can give any advice needed.<br />
<br />
=== What is Synfig Studio native file format? ===<br />
<br />
Synfig Studio uses its own file formats: .sif and .sifz. Sif is a synfig project file while sifz is a compressed (gzipped) sif file. As Sifs are (just) human readable XML, you can save some disk space choosing the compressed one when you save your animations.<br />
<br />
There is no (known) link between [http://filext.com/file-extension/SIF other .sif file formats] or [https://en.wikipedia.org/wiki/Standard_Interchange_Format this one]. ...<br />
<br />
=== Why doesn't synfig use SVG format? ===<br />
<br />
Svg file format come from [http://www.w3c.org World Wide Web Consortium], they <troll on>try to<troll off> take care of standards around the big net....I'm not convicted that creating animated SVG, they were thinking in terms of film quality animation .... like synfig aims to produce ... in other terms, Sif is more than animated SVG.<br />
<br />
Work has been done to implement Cairo render to Synfig that eventually would allow to export without too much effort to SVG as well as to PDF and others back ends. It is very simple to add SVG export just coding a similar exporter like the current PNG one. Anyone want to code that SVG exporter?<br />
<br />
Always taking in mind that you'll lose some native Synfig goodies in the process. Export to SVG (animated or not) could be a great feature to have (in terms of workflow / open format support), although you lose some features.<br />
<br />
=== Procedure entry point ... could not be located? ===<br />
<br />
If you are on Windows and it says "the procedure entry point_ZN6synfig5Color7set_hexERSs could not be located in the dynamic link library libsynfig-0.dll" that means you forgot to upgrade synfig when you upgraded synfigstudio. Due to the dependency systems on Linux you will probably not get this there unless your distro has broken packages. Be sure to install the latest version of synfig and synfigstudio.<br />
<br />
If you get the same error but with gtk, glib, iconv.dll or libxml2.dll you should look for old versions of these DLLs in your Windows directory and rename them to iconv.dll.bak and libxm2.dll.bak etc.<br />
<br />
=== libsynfig-0.dll was not found ===<br />
<br />
If you get the error message "libsynfig-0.dll was not found" please check that you have synfig (as well as synfig studio) correctly installed. <br />
<br />
<div id="Can_I_do_anything_to_improve_the_stability_of_the_Windows_version_of_Synfig.3F"></div><br />
=== Can I do anything to improve the stability of synfigstudio? ===<br />
<br />
If you're running on a Hyperthreading or multi-core CPU (e.g Pentium 4 with Hyperthreading or Intel Core2 Duo or Quadcore, etc.) then you may find Synfig is more stable if you restrict it to run on only one processor. '''Since version 0.62.01 the stability under Windows has increased noticiably. The single thread renderer option has been enabled by default in Synfig Studio.'''<br />
<br />
===== How do I do this on Windows? =====<br />
<br />
To do this on windows, start Synfig Studio, then press Ctrl-Shift-Esc this will start the 'Windows Task Manager', alternatively you can press Ctrl-Alt-Del and choose 'Task Manager'. Select the processes tab, find synfigstudio.exe in the processes list and right click on it. Choose 'Set Affinity...' and make sure only one CPU is checked. Unfortunately, this setting isn't preserved so you either have to do this manually each time you start Synfig Studio or use a tool such as the [http://www.tomshardware.com/2004/05/28/getting_more_bang_out_of_your_dual_processing_buck/index.html Tom's Hardware Guide Task Assignment Manager].<br />
<br />
===== How do I do this on Linux? =====<br />
<br />
On linux, you need to install schedutils.<br />
<br />
Then run synfigstudio like this:<br />
<br />
<pre>taskset -c 0 synfigstudio</pre><br />
<br />
Or if you have synfigstudio open already, run this:<br />
<br />
<pre>taskset -p -c 0 `pgrep synfigstudio`</pre><br />
<br />
=== Why can't I get sound to work? ===<br />
Synfig GUI implies that sound files can be loaded and played with the animation previews, to aid with e.g. lip synching. Synfig relies on a helper library called FMOD to handle sound. Unfortunately, it appears that this feature was not fully implemented, and the 'play' code is commented out. Windows support for sound does not even appear to have been attempted. If you need to need to synch to a soundtrack, the easiest way is to use video editing software to add the sound effects afterwards, or use an audio editor to take careful note of the audio cues, and animate the action to coincide with those timestamps.<br />
<br />
See this page for {{l|Sound Layer|sound}} implementation guidelines.<br />
<br />
=== How do I render moving pictures from Synfig under Windows === <br />
FFMPEG is now distributed as an optional component of the Windows installer (installed by default). If you're looking for a file to include on a web page, rendering to an animated gif file also works (although you may want to use a quality setting of 6 or higher to avoid rendering artifacts). For mpg, there are a couple of options. <br />
<br />
* Use the ffmpeg render target in Synfig to render to an mpg file, or <br />
* If you want more control over the final video file, the best solution may be to render to a sequence of png files and use a separate program, such as the command line version of ffmpeg, to assemble them to a video file. This could also allow you to incorporate an audio track in the same step.<br />
<br />
Be careful where you choose to save your rendered file. If you save it to an area where Microsoft doesn't think you should be writing (like "c:\" or "c:\Program Files\.." etc.) it will pretend to let you, but in fact save it to another location to save yourself. You can find it using a file search, but it won't be where you thought it was. Be safe - save to the desktop or a folder under "c:\Users\yourname\..."<br />
<br />
=== I have a weird problem building from source. What's up? ===<br />
<br />
Your copy of pkg-config probably doesn't look in the right places for .pc files. If you are installing to /usr/local, try running "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig" before building or installing anything.<br />
<br />
=== Why does only the first frame of my animation render? ===<br />
<br />
You probably have '''Use current frame''' checked in the render dialog box.<br />
<br />
=== Why don't I get the colors I'm expecting? ===<br />
<br />
This [http://en.wikipedia.org/wiki/RGB_color_model#Nonlinearity Wikipedia] article talks about how color output is non-linear, that if 0 is black and 100 is white, then 50 is only about 22 percent of the brightness of white, rather than 50% as you might expect.<br />
<br />
In synfig there is an option (on by default) to make sure that if you ask for 50, you get 50% of the brightness of white.<br />
<br />
In the {{l|Toolbox}} see File>Setup which would open the {{l|Setup Dialog}}. Then go to the Misc tab and to the Visually Linear Color Selection checkbox. If you turn that off, everything will go back to its non-linear, yet strangely comfortable and familiar mode.<br />
<br />
=== Why when I create more than one shape, the other one dissapears from the canvas, but its still on the layer bar ? ===<br />
Take a look to the "blend method" to check if it's set to some other one than composite.<br />
<br />
You like to read also {{l|New Layer Defaults}} and {{l|Blend Method Parameter}} pages.<br />
<br />
=== Why doesn't the rotate tool rotate rectangles layers? ===<br />
The {{l|Rotate Tool}} works on {{l|Handle}}. The {{l|Rectangle Layer}} works by drawing horizontal and vertical lines between the two {{l|Handle}}s, so when the rotate tool is used with a rectangle it only rotates the {{l|Handle}}s around the rotation point, but the lines of the rectangle are still horizontal and vertical. What you are probably looking for is the {{l|Layer#Rotate|Rotate Layer}}. <br />
<br />
Good to know, the {{l|Rotate Tool}} has an {{l|Region Layer}} option which allow the behavior you might expect.<br />
<br />
=== Tablet doesn't track as expected ===<br />
When using some programs you may find that the mouse may not track as you would expect.<br />
Synfig, Inkscape and Gimp are ones that I have used that will give odd tracking.<br />
When drawing with the mouse the actual drawing is some distance from the cursor and when<br />
you use the pen the drawing is drawn where the cursor is.<br />
This can be easily fixed with the software that came with the tablet.<br />
<br />
When using the tablet software that came with the graphire 4 tablet you will find<br />
that it uses two different tracking methods for the mouse and pen and these two<br />
tracking methods are called Mouse Mode and Pen Mode.<br />
<br />
The Pen Mode uses absolute positioning, that means the active drawing area of the tablet<br />
is in proportion to the whole screen. Wherever you move the pen the cursor will move<br />
to the corresponding point on the screen, wether you drag the pen or you pick up the<br />
pen and move it to a new location that cursor will move or jump to where the pen is.<br />
<br />
The Mouse Mode uses a positioning system similar to a traditional mouse where you can pick up<br />
and slide the mouse where you wish and the cursor will follow the mouse as it is moved.<br />
It will not jump to new locations on the screen even if you pick up the mouse and place it<br />
in a new position on the tablet, the cursor will just continue from it's last position.<br />
<br />
In the case of the Wacom Graphire 4 tablet that I'm using in Windows XP I needed to open the<br />
program called Pen Tablet and change the settings for the mouse.<br />
To do this open Pen Tablet and you will see four tabs, click the tab marked Mouse and you will<br />
find a box called Tracking with two options. One is Pen Mode and the other is Mouse Mode.<br />
Select the Pen Mode and the mouse will now use absolute positioning.<br />
<br />
=== Why does the Text Tool make Synfig Studio crash? ===<br />
<br />
Occassionally, some users report that Synfig Studio crashes whenever the {{l|Text Tool}} is selected. This is caused by one or more of their currently installed fonts being corrupted or containing non-standard data.<br />
<br />
Once the these fonts are uninstalled, the {{l|Text Tool}} will work correctly.<br />
<br />
=== Can i change user interface language to english? ===<br />
<br />
Synfig respect the Operating System language, great point you can say... but sometime users just want english user interface (helpful to follow tutos' for example). [http://www.synfig.org/issues/thebuggenie/synfig/issues/625 Actually] it's not possible by a user friendly way, but it's possible.<br />
<br />
===== How do I do this on Windows? =====<br />
<br />
I you have already installed Synfig, de-install it. During (re)installing, deselect languages. So only the "native language" of the program left, and you have an English interface now.<br />
<br />
===== How do I do this on Linux? =====<br />
<br />
Open a command terminal, and change the language by exporting a variable with this command '''export LANG=C''' , then from the same terminal you can launch synfigstudio with an english UI. For sure, you can create a script who will do that for you.<br />
<br />
Nota: this way can ''force'' another languages.<br />
<br />
== FAQs relating to earlier Synfig versions ==<br />
<br />
These issues have been addressed in the current version of Synfig.<br />
<br />
=== Why do imported SVG images look bad? ===<br />
<br />
Synfig doesn't have the ability to import SVG images, it can only auto-render them to PNG with imagemagick and import those. The closest you can get to importing complex formats like SVG or XCF is to use one of the {{l|converters}}. <br />
Synfig can import SVG since 0.62.00 release.<br />
<br />
=== Why Synfig 0.61.08 doesn't work in Ubuntu Intrepid 8.10? ===<br />
Due to the incorporation if the newest GTK/GTKmm version (2.14) since Ubuntu Intrepid 8.10, the old version of synfigstudio included in that linux distribution has turned not usable. Until new Ubuntu version or the adoptation of a backport into 8.04 LTS, the only way to have synfigstudio running in Ubuntu Intrepid is build the binaries from he source code. Follow the {{l|build instructions}} or [http://synfig.org/forums/viewtopic.php?f=13&t=277 this thread] to do that.<br />
<br />
=== Where did the polygon, draw and sketch tools go? ===<br />
<br />
They are disabled by default due to problems. Instead of the polygon tool, you should use the bline tool. The draw tool was never completed, is very buggy, and frustrating to use. Since the draw tool is being disabled, then we might as well disable the sketch tool too. You can re-enable them without recompiling by setting some environment variables (you can [http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/environment_variables.mspx set environment variables on windows] too). Set SYNFIG_ENABLE_POLYGON, SYNFIG_ENABLE_DRAW and SYNFIG_ENABLE_SKETCH to 1. On Linux/Unix/MacOSX this is as simple as running these commands in a terminal:<br />
<br />
<pre><br />
export SYNFIG_ENABLE_POLYGON=1<br />
export SYNFIG_ENABLE_DRAW=1<br />
export SYNFIG_ENABLE_SKETCH=1<br />
</pre><br />
<br />
Then run synfigstudio from the same terminal. You can probably find some way of getting these variables set automatically when you log in, but it depends on the distro. In Ubuntu you can put them in ~/.xprofile for example.<br />
<br />
The polygon, draw, and sketch tools will be on by default in future releases of Synfig, from 0.61.07 onwards. They can be disabled by replacing 'ENABLE' with 'DISABLE' in the above lines.<br />
<br />
=== Where did the width tool go? ===<br />
<br />
The {{l|Width Tool}} is '''enabled by default since''' {{l|Releases/0.61.09|Release 0.61.09}}. It can be disabled setting SYNFIG_DISABLE_WIDTH=1 environment variables.<br />
<br />
It was disabled by default due to problems. Instead of the width tool, you should just modify the width ducks directly. You can re-enable it without recompiling by setting an environment variable (you can [http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/environment_variables.mspx set environment variables on windows] too). Set SYNFIG_ENABLE_WIDTH to 1. On Linux/Unix/MacOSX this is as simple as running this command in a terminal:<br />
<br />
<pre><br />
export SYNFIG_ENABLE_WIDTH=1<br />
</pre><br />
<br />
Then run synfigstudio from the same terminal. You can probably find some way of getting this variable set automatically when you log in, but it depends on the distro. In Ubuntu you can put it in ~/.xprofile for example.<br />
<br />
=== Why doesn't walk.sif from the SVN work? ===<br />
<br />
In the SVN repository, there's a walk cycle example, but the sif file includes features that are incompatible with the current version of Synfig. A re-worked example can be found in the {{l|Walk Cycle|Walk Cycle Tutorial}}.<br />
<br />
If you can look at the source code and figure out why the .sif file won't load, we'd love to have a fix.<br />
<br />
=== What happened to my synfig toolbox? ===<br />
<br />
If you no longer have a synfig toolbox, it means the window positions in your settings file for the toolbox got corrupted during a crash or something and your synfig toolbox is now off the screen. You should remove or edit your settings file to get it back. This bug ([http://sf.net/support/tracker.php?aid=1836848 1836848]) was fixed in SVN r1167.<br />
<br />
This is a very common issue on Windows computers. Quick fix: delete C:\Documents and Settings\*your user name*\Synfig. You should not lose any saved work. Synfig will run fine following this fix.<br />
<br />
=== The plant layer doesn't work/displays erratically/doesn't render. Why? ===<br />
<br />
The plant layer should allow pictures [http://home.comcast.net/~pxegeek/synfig/plant11.JPG like this one] to be drawn, but again it had a bug that prevented if from working correctly in Synfig 0.61.06 and earlier. The bug was fixed in svn r620 and release 0.61.07<br />
<br />
Further fixes were later added to stop it crashing when 'stem size' or 'splits' were set too high. <br />
<br />
=== Missing icons? synfig/studio doesn't render anything? ===<br />
<br />
You probably compiled synfig with g++ 4.1 using optimisation level 2 or higher. g++ has a bug that prevents Synfig Studio from compositing the images properly. Please recompile synfig using ./configure --enable-optimization=0 or disable optimisation and then rebuild the synfig images. The binary packages for some GNU/Linux distributions are affected by this. [http://sf.net/tracker/?group_id=144022&atid=757416 Bug] #[http://sf.net/support/tracker.php?aid=1509627 1509627]<br />
<br />
As of svn r774, it is now OK to build with any optimization level. Also, using gcc 4.2.1 or newer it's possible to successfully build old versions of synfig with strong optimization.<br />
<br />
=== synfigstudio can't find icons? ===<br />
<br />
(I know they rendered fine, but they show up with red crosses everywhere).<br />
<br />
This is #[http://sf.net/support/tracker.php?aid=1568925 1568925] that was introduced in SVN 180. Workaround is to set an environment variable at runtime like this: export SYNFIG_ROOT=/usr (or similar) or just install into /usr/local instead. Fixed in SVN r486.<br />
<br />
=== I'm using synfigstudio on a laptop but can't draw anything using my mouse. What gives? ===<br />
<br />
Try disabling the the touchpad from the input devices dialog. Unfortunately synfigstudio will not remember this setting so you have to do it every time you start synfigstudio.<br />
<br />
This was fixed in [http://kibi.dyndns.org:8083/~dooglus/gitweb.pl?p=synfig;a=commitdiff;h=r487 svn r487] and so synfig 0.61.06 and newer won't have this problem.<br />
<br />
=== Why is everything yellow? / Why are all the colors wrong? ===<br />
<br />
This can happen when you switch between locales, due to a bug in version 0.61.05. It's fixed in the subversion repository (r228). To work around the problem, do the following: from the main window, choose File>Setup what would open the {{l|Setup Dialog}}, then select the Gamma tab and set all 3 sliders back to the default value of 2.2.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Main_Page&diff=19984Main Page2015-01-02T11:48:32Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Synfig Wiki}}<br />
<!-- Page info end --><br />
<br />
Welcome to the Synfig wiki. This wiki is the main documentation for the [http://www.synfig.org/ Synfig Project], a 2D animation and design program. The wiki documentation is divided in three main sections: {{l|User Documentation}} (for the users of the animation program), {{l|Developer Documentation}} (for the people developing the code of the program) and {{l|Writer Documentation}} (for the people that wish to keep this wiki up to date).<br />
<br />
Below is a list of all the items for each category of documentation.<br />
<br />
* '''{{l|User Documentation}}'''<br />
** {{l|:Category:Manual|Manual}}. The Manual is a step by step walkthrough of the main aspects of Synfig Studio and the workflow to do animations with it. A snapshot is available for offline viewing from http://www.mediafire.com/?ucindxh81z8uga5<br />
** {{l|:Category:Tutorials|Tutorials}}. Each tutorial is an independent guide that illustrates how to proceed to achieve a particular task.<br />
** {{l|:Category:Reference|Reference}}. This is an exhaustive list of all the individual aspects of Synfig (GUI and command line). Use it when you need details on a particular aspect of the program.<br />
** {{l|:Category:Glossary|Glossary}}. Some parts of the documentation have Synfig-specific naming or concepts. Research them here.<br />
* '''{{l|Developer Documentation}}'''<br />
* '''{{l|Writer Documentation}}'''<br />
<br />
<br />
<br />
'''To all writers and translators'''<br />
<br />
Please read the hints at {{l|Writer Documentation}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Download&diff=19983Download2015-01-02T11:48:11Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
OutDated page since 2011 - For fresh meat (or beans) take a look to http://www.synfig.org/cms/en/download/<br />
<br />
== Current Release ==<br />
<br />
<!-- GNU/Linux --><br />
{| style="width:100%;"<br />
|-<br />
! colspan = "3" style="padding:10px;" | '''GNU/Linux'''<br />
|-<br />
| style="padding:5px; width:30%;" |<br />
| style="padding:5px; width:30%;" |<br />
|-<br />
| '''Synfig 0.61.09 (RPM)'''<br />
| '''Synfig 0.61.09 (DEB)'''<br />
| '''Synfig 0.61.09 (TAR.BZ2)'''<br />
|-<br />
|<br />
|-<br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://download.tuxfamily.org/morevna/morevnapackage/binaries/0.61.09/synfigstudio-0.61.09-2113.binary.1.i386.rpm synfigstudio (i386)] <br> [http://download.tuxfamily.org/morevna/morevnapackage/binaries/0.61.09/synfigstudio-0.61.09-2113.binary.1.x86_64.rpm synfigstudio (x86_64)]</div><br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://download.tuxfamily.org/morevna/morevnapackage/binaries/0.61.09/synfigstudio_0.61.09-2113.binary.1_i386.deb synfigstudio (i386)] <br> [http://download.tuxfamily.org/morevna/morevnapackage/binaries/0.61.09/synfigstudio_0.61.09-2113.binary.1_amd64.deb synfigstudio (x86_64)]</div><br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://download.tuxfamily.org/morevna/morevnapackage/binaries/0.61.09/synfigstudio-0.61.09-2113.binary.1.i386.tar.bz2 synfigstudio (i386)] <br> [http://download.tuxfamily.org/morevna/morevnapackage/binaries/0.61.09/synfigstudio-0.61.09-2113.binary.1.x86_64.tar.bz2 synfigstudio (x86_64)]</div><br />
|-<br />
| style="padding:3px;" |<br />
|-<br />
| style="vertical-align:top;" | Suits most recent RPM-based Linux distributions (RedHat, Fedora, Mandriva).<br />
| style="vertical-align:top;" | Suits most recent Debian-based Linux distributions (Debian, Ubuntu).<br />
| style="vertical-align:top;" | Suits most recent Linux distributions, no requiments for package management system, highly portable, but no desktop integration.<br />
|-<br />
| colspan = "3" style="padding-bottom:15px;" | <hr> NOTE: If your GNU/Linux {{l|Distributions|distribution}} already have a recent Synfig Studio package in repositories then it's preferred to use them, as the distribution maintainers take care of all the dependencies and bug fix updates. Packages above provide the quick and easy way to install and run latest Synfig Studio on most GNU/Linux systems. But because of their unified nature they have many dependent libraries included and we're unable to keep track of their bugfix updates. So installing them could be a security risk. If you have encounter any problems with those packages, report them [http://synfig.org/forums/viewtopic.php?f=16&t=341 here].<br />
|}<br />
<!-- Windows --><br />
{| style="width:100%;"<br />
|-<br />
! colspan = "3" style="padding:10px;" | '''Windows'''<br />
|-<br />
| style="padding:5px; width:30%;" |<br />
|-<br />
| '''Synfig 0.61.09 (EXE)'''<br />
|-<br />
|<br />
|-<br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://downloads.sourceforge.net/gladewin32/gtk-2.10.11-win32-1.exe gtk] [http://ftp.gnome.org/pub/gnome/binaries/win32/gtkmm/2.10/gtkmm-win32-runtime-2.10.11-1.exe gtkmm] [http://downloads.sourceforge.net/synfig/synfig-0.61.09.exe synfig] [http://downloads.sourceforge.net/synfig/synfigstudio-0.61.09.exe synfigstudio]</div><br />
|-<br />
| style="padding:3px;" |<br />
|-<br />
| style="vertical-align:top;" | Suitable for Windows XP/Vista (both 32bit and 64bit). All four packages are required, see the [http://uk.youtube.com/watch?v=mrDqiRI7fwk install walkthrough video].<br />
|-<br />
| <br />
|<br />
|<br />
|-<br />
| colspan = "3" style="padding-bottom:15px;" | <hr> NOTE: There are {{l|Security|security issues}} with the dv, imagemagick and ffmpeg targets, please avoid using them to import or render untrusted files. Rendering issues may be encountered on Hyperthreaded or multi-core CPUs. Please see the FAQ for {{l|FAQ#Can_I_do_anything_to_improve_the_stability_of_the_Windows_version_of_Synfig.3F|workaround details}}.<br />
|}<br />
<!-- MacOS X --><br />
{| style="width:100%;"<br />
|-<br />
! colspan = "3" style="padding:10px;" | '''MacOS X'''<br />
|-<br />
| style="padding:5px; width:30%;" |<br />
|-<br />
| '''Synfig 0.61.09 (Native)'''<br />
| '''Synfig 0.61.09 (Homebrew)'''<br />
|-<br />
|<br />
|-<br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">Taken offline.</div><br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[https://github.com/mxcl/homebrew/Library/Formula/etl.rb etl] [https://github.com/mxcl/homebrew/Library/Formula/synfig.rb synfig] [https://github.com/secondplanet/homebrew/tree/synfigstudio/Library/Formula/synfigstudio.rb synfigstudio]</div><br />
|-<br />
| style="padding:3px;" |<br />
|-<br />
| style="vertical-align:top;" | Please see bug [http://sf.net/support/tracker.php?aid=1686495 1686495]. Patches and volunteers to create new packages are welcome. Until someone volunteers, you can {{l|Building_On_Mac_OS_X|build it yourself}} or install via homebrew.<br />
| style="vertical-align:top;" | Installing synfigstudio will install all dependencies.<br />
|-<br />
| colspan = "3" style="padding-bottom:15px;" | <hr> <br />
|}<br />
<!-- Source code --><br />
{| style="width:100%;"<br />
|-<br />
! colspan = "3" style="padding:10px;" | '''Source code'''<br />
|-<br />
| style="padding:5px; width:30%;" |<br />
| style="padding:5px; width:30%;" |<br />
| style="padding:5px; width:30%;" |<br />
|-<br />
| '''Synfig 0.61.09 (TAR.GZ)'''<br />
|-<br />
|<br />
|-<br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://sf.net/project/showfiles.php?group_id=144022&package_id=198849 ETL] [http://sf.net/project/showfiles.php?group_id=144022&package_id=158279 synfig] [http://sf.net/project/showfiles.php?group_id=144022&package_id=198850 synfigstudio]</div><br />
|-<br />
| style="padding:3px;" |<br />
|-<br />
| style="vertical-align:top;" | Please read the {{l|Build instructions|build instructions}}.<br />
|-<br />
| colspan = "3" style="padding-bottom:10px;" | <hr><br />
|}<br />
<br />
= Development snapshots =<br />
<!-- GNU/Linux --><br />
{| style="width:100%;"<br />
|-<br />
! colspan = "3" style="padding:10px;" | '''GNU/Linux'''<br />
|-<br />
| style="padding:5px; width:30%;" |<br />
| style="padding:5px; width:30%;" |<br />
|-<br />
| '''Synfig 0.61.09 20090922 (RPM)'''<br />
| '''Synfig 0.61.09 20090922 (DEB)'''<br />
| '''Synfig 0.61.09 20090922 (TAR.BZ2)'''<br />
|-<br />
|<br />
|-<br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://download.tuxfamily.org/morevna/morevnapackage/binaries/synfigstudio-0.61.09-20090922.master.1.i386.rpm synfigstudio (i386)] <br> [http://download.tuxfamily.org/morevna/morevnapackage/binaries/synfigstudio-0.61.09-20090922.master.1.x86_64.rpm synfigstudio (x86_64)]</div><br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://download.tuxfamily.org/morevna/morevnapackage/binaries/synfigstudio_0.61.09-20090922.master.1_i386.deb synfigstudio (i386)] <br> [http://download.tuxfamily.org/morevna/morevnapackage/binaries/synfigstudio_0.61.09-20090922.master.1_amd64.deb synfigstudio (x86_64)]</div><br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://download.tuxfamily.org/morevna/morevnapackage/binaries/synfigstudio-0.61.09-20090922.master.1.i386.tar.bz2 synfigstudio (i386)] <br> [http://download.tuxfamily.org/morevna/morevnapackage/binaries/synfigstudio-0.61.09-20090922.master.1.x86_64.tar.bz2 synfigstudio (x86_64)]</div><br />
|-<br />
| style="padding:3px;" |<br />
|-<br />
| style="vertical-align:top;" | Suits most recent RPM-based Linux distributions (RedHat, Fedora, Mandriva).<br />
| style="vertical-align:top;" | Suits most recent Debian-based Linux distributions (Debian, Ubuntu).<br />
| style="vertical-align:top;" | Suits most recent Linux distributions,no requiments for package management system, highly portable, but no desktop integration.<br />
|-<br />
| colspan = "3" style="padding-bottom:15px;" | <hr> NOTE: If your GNU/Linux {{l|Distributions|distribution}} already have a recent Synfig Studio package in repositories then it's preferred to use them, as the distribution maintainers take care of all the dependencies and bug fix updates. Packages above provide the quick and easy way to install and run latest Synfig Studio on most GNU/Linux systems. But because of their unified nature they have many dependent libraries included and we're unable to keep track of their bugfix updates. So installing them could be a security risk. If you have encounter any problems with those packages, report them [http://synfig.org/forums/viewtopic.php?f=16&t=341 here].<br />
|}<br />
<!-- Windows --><br />
{| style="width:100%;"<br />
|-<br />
! colspan = "3" style="padding:10px;" | '''Windows'''<br />
|-<br />
| style="padding:5px; width:30%;" |<br />
|-<br />
| '''Synfig 0.61.09 SVN2375 (EXE)'''<br />
|-<br />
|<br />
|-<br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://downloads.sourceforge.net/gladewin32/gtk-2.10.11-win32-1.exe gtk] [http://ftp.gnome.org/pub/gnome/binaries/win32/gtkmm/2.10/gtkmm-win32-runtime-2.10.11-1.exe gtkmm] [http://synfig.org/files/synfig-0.61.09-2375.exe synfig] [http://synfig.org/files/synfigstudio-0.61.09-2375.exe synfigstudio]</div><br />
|-<br />
| style="padding:3px;" |<br />
|-<br />
| style="vertical-align:top;" | Suitable for Windows XP/Vista (both 32bit and 64bit). All four packages are required, see the [http://uk.youtube.com/watch?v=mrDqiRI7fwk install walkthrough video].<br />
|-<br />
| <br />
|<br />
|<br />
|-<br />
| colspan = "3" style="padding-bottom:15px;" | <hr> NOTE: There are {{l|Security|security issues}} with the dv, imagemagick and ffmpeg targets, please avoid using them to import or render untrusted files. Rendering issues may be encountered on Hyperthreaded or multi-core CPUs. Please see the FAQ for {{l|FAQ#Can_I_do_anything_to_improve_the_stability_of_the_Windows_version_of_Synfig.3F|workaround details}}.<br />
|}<br />
<!-- Source code --><br />
{| style="width:100%;"<br />
|-<br />
! colspan = "3" style="padding:10px;" | '''Source code'''<br />
|-<br />
| style="padding:5px; width:30%;" |<br />
| style="padding:5px; width:30%;" |<br />
| style="padding:5px; width:30%;" |<br />
|-<br />
| '''Synfig Development (TAR.GZ)'''<br />
|-<br />
| <div style="float:left;">http://synfig.org/images/0/01/PackageIcon.jpg</div> <div style="margin:0 0 0 42px;">[http://synfig.git.sourceforge.net/git/gitweb.cgi?p=synfig;a=snapshot;h=HEAD;sf=tgz ETL synfig synfigstudio]</div><br />
|-<br />
| style="padding:3px;" |<br />
|-<br />
| style="vertical-align:top;" | Please read the {{l|Build_instructions|build instructions}}. Browse repository [http://synfig.git.sourceforge.net/git/gitweb.cgi?p=synfig here].<br />
|-<br />
| colspan = "3" style="padding-bottom:20px;" | <hr><br />
|}<br />
<br />
A special thanks to [http://www.bridgetone.com/ Bridgetone] for hosting our videos and early downloads!</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=About&diff=19982About2015-01-02T11:47:48Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>{{NewTerminology}}<br />
<br />
{{l|File:yk_prologue_172.jpg|left}}<br />
<br />
'''Synfig is a powerful, industrial-strength vector-based 2D animation software package, designed from the ground-up for producing feature-film quality animation with fewer people and resources.'''<br />
<br />
'''While there are many other programs currently on the market to aid with the efficient production of 2D animation, we are currently unaware of any other software that can do what our software can.'''<br />
<br />
== Background ==<br />
<br />
[http://en.wikipedia.org/wiki/Traditional_animation 2D Animation] has traditionally been very expensive because every frame must be drawn by hand. Even with today's digital inking and painting software, the process still relies on individuals hand-drawing each frame. This laborious task is called "[http://en.wikipedia.org/wiki/Tweening tweening]".<br />
<br />
Synfig eliminates the task of manual tweening, producing smooth, fluid motion without the animator having to draw out each frame individually. This allows you to produce 2D animation with fewer people while producing art of a higher quality.<br />
<br />
You may be interested in the {{l|history}} or {{l|features}} of Synfig Studio.<br />
<br />
== Quotes ==<br />
<br />
"that was the original idea from day one---the elimination of the tweening process. But it is certainly not the only feature of Synfig that makes it unique. In addition to eliminating the tweening process, I also wanted Synfig to be used for pretty much every part of production except story-boarding and editing." (OSNews, Robert Quattlebaum) [http://osnews.com/story.php?news_id=13241]</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Gallery&diff=19981Gallery2015-01-02T11:47:29Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>{{Deprecated|http://synfig.org/cms/en/gallery/}}<br />
<br />
Here you can find examples of works created with Synfig by the community and by the artists at Voria Studios.<br />
<br />
== Community ==<br />
<br />
You are welcome to {{l|Contact|share your work with us}} so we can see how synfig is being used. <br />
You are encouraged to distribute your source files (.sif and so on) so others can learn from your work. Obviously this is only if you have permission to distribute all of it.<br />
<br />
=== Finished works ===<br />
<br />
Lots of works are being created with synfig, but here are a few examples of what can be done with it. You can find more videos and images in the {{l|Challenges/All|challenges}}, in the [http://synfig.org/forums/viewforum.php?f=19 artwork forums] and on [http://youtube.com/results?search_query=synfig&search_sort=video_date_uploaded youtube], [http://search.deviantart.com/?section=browse&q=synfig&qh=sort:time deviantART], [http://www.flickr.com/photos/tags/synfig/ flickr], [http://video.google.com/videosearch?q=synfig&so=1 google video], maybe [http://images.google.com/images?q=synfig google images] and maybe on some {{l|Press|blogs or articles about synfig}}. In particular, all of [http://youtube.com/profile_videos?user=ullebulle ullebulle]'s youtube videos have links to the [http://www.musikboden.se/synfigfiles/ corresponding .sif files].<br />
<br />
{|<br />
|-valign="top"<br />
|width="33%" align="center"|<br />
'''Eyes'''<br><br />
{{l|Image:Eyes.png|200px}}<br><br />
Some eyes<br><br />
By Madsen | {{l|Media:Eyes.mp4|Video}} | {{l|Media:Eyes.sif|Source}}<br />
|width="33%" align="center"|<br />
'''Plant Layer Example'''<br><br />
{{l|Image:plant12.png|200px}}<br><br />
An example of what the plant layer can do.<br><br />
By {{l|User:Pxegeek|Pixelgeek}}<br />
|width="33%" align="center"|<br />
'''Windows XP Sanddunes'''<br><br />
{{l|Image:Sanddunes.png|200px}}<br><br />
Synfig version of the "Wind" WinXP wallpaper.<br><br />
By {{l|User:Pxegeek|Pixelgeek}} | [http://www.mediafire.com/?8ve7ytzfuxs Video]<br />
|-valign="top"<br />
|width="33%" align="center"|<br />
'''Synfig cat'''<br><br />
{{l|Image:15357482_p.png|200px}}<br><br />
Synfig cat<br><br />
By {{l|User:rore|Rore}} | [http://youtube.com/watch?v=HW0plbXbPxk Video]<br />
|width="33%" align="center"|<br />
'''Synfig Tux'''<br><br />
{{l|Image:SynfigTux.png|200px}}<br><br />
Tux, with a Synfig logo.<br />
(With acknowledgment to Larry Ewing and the Gimp.)<br><br />
By {{l|User:Pxegeek|Pixelgeek}} | [http://home.comcast.net/~pxegeek/synfig/synfigtux.sif Source]<br />
|width="33%" align="center"|<br />
'''A Jedi's Pencil'''<br><br />
{{l|Image:Jedi pencil.tn.jpg|200px}}<br><br />
Example of visual effects and rotoscoping done in the synfig.<br><br />
By {{l|User:AkhIL|AhkIL}} | [http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF-8&sl=ru&tl=en&u=http://akhil.homelinux.org/wiki/%25D0%2592%25D0%25B8%25D0%25B4%25D0%25B5%25D0%25BE&rurl=translate.google.com&twu=1&usg=ALkJrhhffz7pYHntwGPGAbk6voEBem-aXg#A.2BBBoEMARABDAEPQQ0BDAESA_.2BBBQENgQ1BDQEMARP- Video] | {{l|Media:Jedi_pencil.tar.bz2|Source}}<br />
|-valign="top"<br />
|width="33%" align="center"|<br />
'''Cut The Circle'''<br><br />
{{l|Image:Logo-1.png|Cut the Circle Logo|200px}}<br />
<br />
<!--<br />
<gallery widths="80px" heights="50px" perrow="2"><br />
Image:01-01-marble.png|Marble scene<br />
Image:03-01-lego.png|Lego Scene<br />
Image:04-01-plane.png|Plane scene<br />
Image:08-01-factory.png|Factory scene<br />
Image:09-01-privation.png|Privation Scene<br />
</gallery><br />
--><br />
'''The first short open movie created with Synfig Studio'''. <br />
First Prize in the [http://selfproject.eu SELF Project] Video Contest. An animation about education, sharing and copyright.<br><br />
By {{l|User:Yaco|Yaco}} | [http://www.icaro.org.ar/proyectos/ctc/doku.php Source | Video | Info]<br />
|width="33%" align="center"|<br />
'''Mr. Tip Toe Adventures'''<br />
{{l|Image:portada.jpg|200px}}<br><br />
Animation based on a child drawings of an invented character of [http://en.wikipedia.org/wiki/Mr._Men Mr. Men] series.<br><br />
By {{l|User:Genete|Genete}} | [http://www.darthfurby.com/genete/synfig/donempinado.zip Source] | [http://www.youtube.com/watch?v=uHCpbMmT5GE Video]<br />
|width="33%" align="center"|<br />
'''Animated Synfig logo'''<br><br />
http://i85.photobucket.com/albums/k74/Genete/synfig/splash-animated-o.gif<br><br />
An animated version of {{l|User:Rore|rore}}'s splash screen.<br><br />
By {{l|User:Genete|Genete}} | [http://synfig.org/forums/download/file.php?id=129 Source]<br />
|-valign="top"<br />
|width="33%" align="center"|<br />
'''Victory Day 2008'''<br><br />
{{l|Image:9may2008.tn.jpg|200px}}<br><br />
Social advertisement about [http://en.wikipedia.org/wiki/Victory_Day_(Eastern_Europe) 9 may 1945].<br />
Combining video, photo, 3d and 2d. Final compositing done in synfig.<br><br />
By {{l|User:AkhIL|AhkIL}} | [http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF-8&sl=ru&tl=en&u=http://akhil.homelinux.org/wiki/%25D0%2592%25D0%25B8%25D0%25B4%25D0%25B5%25D0%25BE&rurl=translate.google.com&twu=1&usg=ALkJrhhffz7pYHntwGPGAbk6voEBem-aXg#A.2BBBQENQQ9BEw_.2BBD8EPgQxBDUENARL_2008 Video] <br />
|width="33%" align="center"|<br />
'''Traffic Police'''<br><br />
{{l|Image:gibdd.tn.jpg|200px}}<br><br />
Social advertisement done for Russian State Inspection for Road Traffic Safety.<br />
Backgrounds painted in "mypaint".<br />
<br><br />
By {{l|User:AkhIL|AhkIL}} | [http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF-8&sl=ru&tl=en&u=http://akhil.homelinux.org/wiki/%25D0%2592%25D0%25B8%25D0%25B4%25D0%25B5%25D0%25BE&rurl=translate.google.com&twu=1&usg=ALkJrhhffz7pYHntwGPGAbk6voEBem-aXg#A.2BBB8EPg_.2BBDQEPgRABD4EMwQ1_.2BBDEENQQ3_.2BBD4EMwQ7BE8ENAQ6BDg- Video] <br />
|width="33%" align="center"|<br />
'''Synfig Demo Reel'''<br><br />
{{l|Image:Sdr final.gif}}<br><br />
A showcase of the capabilities of Synfig to generate interest in Synfig amongst artists and coders.<br><br />
By {{l|User:Pxegeek|Pixelgeek}} and others|[http://synfig.org/DemoReel More Info]|[http://www.archive.org/details/SynfigDemoReel Video]<br />
|-valign="top"<br />
|width="33%" align="center"|<br />
'''Insect'''<br><br />
{{l|Image:Insectrip.png|200px}}<br><br />
A bug<br><br />
By {{l|User:Satrip|Satrip}} | [http://synfig.org/forums/download/file.php?id=452 Source]<br />
|}<br />
<br />
<br />
<!--<br />
This section commented out as the links are no longer valid. pixelgeek 4/26/08<br />
|-valign="top"<br />
| width="50%" align="center"|<br />
'''Simple Efect" animation'''<br />
[http://graphics.birt.at/synfig/efect.avi "Simple Efect" animation (XviD) by lucianDesign]<br />
[http://graphics.birt.at/synfig/efect2.zip Download "Simple Efect 2" source file]<br />
Created by lucianDesign.<br />
--><br />
<br />
=== Work in progress ===<br />
<br />
This section lists notable community projects in progress using Synfig. For more Synfig works in progress, please visit the [http://synfig.org/forums/viewforum.php?f=6 WIP forum].<br />
<br />
{|<br />
|-valign="top"<br />
|width="33%"|<br />
'''Morevna Project'''<br><br />
A full-length animated movie based on the Russian fairy-tale "Marya Morevna".<br><br />
By {{l|User:Zelgadis|Zelgadis}} and others | [http://morevnaproject.org/ More info] | [http://synfig.org/forums/viewtopic.php?f=6&t=89 Preview]<br />
|}<br />
<br />
== Voria ==<br />
<br />
'''ALL''' of the videos and images in this section were created using Synfig, and are all 2D. No 3D software was used in the production of these videos and images. They were all produced by artists from {{l|History|Voria Studios}} when synfig was a proprietary product. More can be found in darco's [http://www.deepdarc.com/module/album/?prnt=1 art album].<br />
<br />
For videos and stills produced since synfig became free software, see the {{l|#Community|community}} section.<br />
<br />
=== Videos ===<br />
<br />
{|<br />
|-valign="top"<br />
| width="50%"|<br />
'''Werewolf'''<br />
<br />
[http://www.youtube.com/watch?v=AW-_WqdbqYY http://synfig.org/files/voria/wolf-t.jpg]<br />
<br />
[http://www.bridgetone.com/voria/movies/wolf.mov Download] (around 45 seconds, 1.6 megabytes) November 2004<br />
<br />
A werewolf transforms into his beastly state as the red moon rises.<br />
<br />
Created by Will Short, Robert Quattlebaum and Darrin Michelson<br />
<br />
[http://synfig.org/files/voria/werewolf.zip Source code] is available, for educational use only, do not distribute or distribute modified renders.<br />
<br />
| width="50%"|<br />
''' Big Eye '''<br />
<br />
[http://www.youtube.com/watch?v=nAYdf-CJwPo http://synfig.org/files/voria/bigeye-t.jpg]<br />
<br />
[http://www.bridgetone.com/voria/movies/eye.mov Download] (around 15 seconds, 2.5 megabytes) October 2004<br />
<br />
A close-up of a large, lazy eye. Notice how the reflection actually distorts as the lense moves under it.<br />
<br />
Created by Rabecha Lenhart and Robert Quattlebaum<br />
<br />
[https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-core/trunk/examples/eye.sifz Source code] is available under the same {{l|license}} as synfig (GNU GPL 2).<br />
|-valign="top"<br />
|<div id="Prologue"><br />
''' Prologue '''<br />
<br />
[http://www.youtube.com/watch?v=wwSZZivjQMo http://img.youtube.com/vi/wwSZZivjQMo/default.jpg]<br />
<br />
[http://www.bridgetone.com/voria/movies/prologue.mov Download] (around 3 minutes, 20 megabytes) July 2004<br />
<br />
This short follows two children fleeing from soldiers through an old sewer. In an attempt to protect his friend, one of the children tries to draw one of the soldiers away. However, plans don't always work out as one would hope. This was the first animated production created using Synfig, and as such has become our “proof of concept” animation for it.<br />
<br />
Created by: Voria Studios<br />
<br />
[http://synfig.org/files/voria/prologue.zip Source code] is available, for educational use only, do not distribute or distribute modified renders.<br />
<br />
</div><br />
|<br />
''' Happy Fun-Joy Time Start! '''<br />
<br />
[http://www.youtube.com/watch?v=QKQI7-mMvyg http://synfig.org/files/voria/kam2-t.jpg]<br />
<br />
[http://www.bridgetone.com/voria/movies/kam.mov Download] (around 22 seconds, 2.9 megabytes) December 2004<br />
<br />
A very bizzare, super-happy, and oddly captivating animation featuring large purple bears, dancing children, smiling celestial bodies, rainbows, leaping sheep, and dancing flowers.<br />
<br />
Created by Rabecha Lenhart<br />
|}<br />
<br />
=== Stills ===<br />
<br />
Several of these have source code in the synfig {{l|Source code|source code repository}}, all {{l|License|licensed}} under the GNU GPL 2.<br />
<br />
<gallery><br />
Image:Pirates of Voria.png|Pirates of Voria <br />
Image:MacWolfen.png|Dr. MacWolfen PI <!-- He'll cure what ails you. --><br />
Image:Eroded Metal.png|Eroded Metal<br />
Image:Big Eye.png|Big Eye<br />
Image:Big Eye Composite.png|Big Eye (Composite)<br />
Image:Museum Backdrop 1.png|Museum Backdrop 1<br />
Image:Museum Backdrop 2.png|Museum Backdrop 2<br />
Image:Museum Backdrop 3.png|Museum Backdrop 3<br />
Image:Fun-Joy Night.png|Fun-Joy Night<br />
Image:Fun-Joy Day.png|Fun-Joy Day<br />
Image:Werewolf.png|Werewolf<br />
Image:Young Child.png|Young Child<br />
</gallery></div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Convert&diff=19980Convert2015-01-02T11:46:57Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Convert}}<br />
{{Category|Glossary}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
<br />
Right-clicking on a value in the {{l|Parameters Panel}} brings up a context menu which has a sub-menu called {{Literal|Convert}}. The {{Literal|Convert}} menu allows you to specify that the parameter should be controlled automatically in various ways or used in mathematical formulas. Depending on the type of the parameter the Convert menu will contain different options.<br />
<br />
To convert the parameter back to its original type, select {{Literal|Disconnect}} from its context menu.<br />
<br />
== Convert Types ==<br />
<br />
=== Add ===<br />
<br />
Converting a parameter to {{Literal|Add}} adds three sub-parameters, the first two of which are the same type as the parameter itself:<br />
* <param> "LHS"<br />
* <param> "RHS"<br />
* real "Scalar"<br />
<br />
The {{Literal|Add}} conversion can be used with parameters of type {{l|Convert#Angle|angle}}, {{l|Convert#Color|color}}, {{l|Convert#Gradient|gradient}}, {{l|Convert#Integer|integer}}, {{l|Convert#Real|real}}, {{l|Convert#Time|time}}, and {{l|Convert#Vector|vector}}.<br />
<br />
The resulting value is:<br />
(LHS + RHS) * Scalar<br />
<br />
=== And ===<br />
<br />
Converting a {{l|Convert#Bool|bool}} parameter to {{Literal|And}} adds two sub-parameters:<br />
* bool "Link1"<br />
* bool "Link2"<br />
<br />
The resulting value is true only if both Link1 and Link2 are true.<br />
<br />
<br />
=== Angle String ===<br />
<br />
Converting an {{l|Convert#String|string}}-valued parameter to {{Literal|Angle String}} adds four sub-parameters:<br />
* angle "Angle"<br />
* integer "Width"<br />
* integer "Precision"<br />
* bool "Zero Padded"<br />
<br />
The resulting value a string containing the value of {{Literal|Angle}} (in degrees) formatted as a string with a minimum width {{Literal|Width}}, with {{Literal|Precision}} decimal places. If {{Literal|Zero Padded}} is true, it will be left-padded with '''0''' characters.<br />
<br />
=== aTan2 ===<br />
<br />
Converting an {{l|Convert#Angle|angle}}-valued parameter to {{Literal|aTan2}} adds two sub-parameters:<br />
* real "X"<br />
* real "Y".<br />
<br />
The resulting value is:<br />
atan2(y,x)<br />
<br />
ie. atan(y/x) but without an error when x is '''0'''. The value is the angle between the x axis and the vector (x,y).<br />
<br />
=== Spline ===<br />
<br />
Converting a {{l|Convert#List|list}} parameter to {{Literal|Spline}} doesn't seem to change anything. Perhaps that's the default type for lists of vertices, such as are found in outlines and regions?<br />
<br />
=== Compare ===<br />
<br />
Converting a {{l|Convert#Bool|bool}} parameter to {{Literal|Compare}} adds five sub-parameters:<br />
* real "LHS"<br />
* real "RHS"<br />
* bool "Greater than"<br />
* bool "Equal to"<br />
* bool "Less than"<br />
<br />
The valuenode compares {{Literal|LHS}} and {{Literal|RHS}}. The three boolean values determine which comparison returns '''true'''. For example, if LHS>RHS and {{Literal|Greater than}} is checked, the valuenode will evaluate to '''true'''.<br />
<br />
=== Composite ===<br />
<br />
Converting a {{l|Convert#Spline Point|Spline Point}} parameter to {{Literal|Composite}} adds six sub-parameters:<br />
* vector "Vertex"<br />
* real "Width"<br />
* real "Origin"<br />
* bool "Split Tangents"<br />
* vector "Tangent 1"<br />
* vector "Tangent 2"<br />
<br />
Converting a {{l|Convert#Color|color}} parameter to {{Literal|Composite}} adds four real-valued sub-parameters:<br />
* real "Red"<br />
* real "Green"<br />
* real "Blue"<br />
* real "Alpha"<br />
<br />
Converting a {{l|Convert#Segment|segment}} parameter to {{Literal|Composite}} adds four vertex sub-parameters:<br />
* vertex "Vertex 1"<br />
* vertex "Tangent 1"<br />
* vertex "Vertex 2"<br />
* vertex "Tangent 2"<br />
<br />
Converting a {{l|Convert#Vector|vector}} parameter to {{Literal|Composite}} adds two real-valued sub-parameters:<br />
* real "X-Axis"<br />
* real "Y-Axis"<br />
<br />
The resulting value is a Spline Point, Color, Segment, or Vector made by combining the component parts.<br />
<br />
=== Cos ===<br />
<br />
Converting a {{l|Convert#Real|real}}-valued parameter to {{Literal|Cos}} adds two sub-parameters:<br />
* angle "Angle"<br />
* real "Amplitude".<br />
<br />
The resulting value is:<br />
{{Literal|Amplitude}} * cos({{Literal|Angle}})<br />
<br />
=== Dot Product ===<br />
<br />
Converting a {{l|Convert#Real|real}} or {{l|Convert#Angle|angle}} parameter to a {{Literal|Dot Product}} adds two sub-parameters:<br />
* vector "LHS"<br />
* vector "RHS"<br />
<br />
If the converted value is an angle, the return value is the angle between the two vectors:<br />
<br />
return = acos((LHS · RHS) / (|LHS| * |RHS|))<br />
<br />
If the converted value is a real, the result value is the dot product of the two vectors:<br />
<br />
return = LHS · RHS = |LHS| * |RHS| * cos(alpha)<br />
<br />
(where alpha is the angle between {{Literal|LHS}} and {{Literal|RHS}}).<br />
<br />
=== Duplicate ===<br />
<br />
This ValueNode type is only used by the {{l|Duplicate Layer}}. It never appears in the {{Literal|Convert}} menu. It is used to control the range of the Index in the Duplicate Layer (q.v.).<br />
<br />
The {{Literal|Duplicate}} ValueNode type has 3 real-valued sub-parameters:<br />
<br />
* real "From"<br />
* real "To"<br />
* real "Step"<br />
<br />
The value of the ValueNode varies from the value of {{Literal|From}} to the value of {{Literal|To}} in steps of size {{Literal|Step}}. The sign of {{Literal|Step}} is ignored. If From<To the steps are positive, else they're negative.<br />
<br />
=== Dynamic ===<br />
<br />
Allows to link two vectors with a dynamic link. The ValueNode (vector type) that is converted to {{Literal|Dynamic}} will be linked to another vector value using a linear/rotational spring system with damping and friction.<br />
<br />
Once you convert the Value to {{Literal|Dynamic}} it offers the following sub-parameters:<br />
<br />
* vector {{Literal|Tip Static}} This is the equilibrium position of the system without external forces relative to the Origin. See Origin. Since it is a vector its length is used for the linear spring equilibrium length and its angle form the x axis is used for the torsion spring equilibrium angle. The initial value of this subparameter is the current value of the Value that is being converted to Dynamic.<br />
* vector {{Literal|Origin}} This is the basement of the dynamic system. Defaults to ('''0.0''', '''0.0'''). If the user changes this value the final equilibrium calculated position of the value is modified too. Accelerations of the Origin are used to move the Tip due to the fictitious forces needed to apply under non inertial reference systems.<br />
* vector {{Literal|Force}} External force applied on the Tip of the dynamic system. Defaults to ('''0.0''', '''0.0''').<br />
* real {{Literal|Torque}} External momentum applied tot he dynamic system at the Origin. Defaults to '''0.0'''.<br />
* real {{Literal|Damping}} Damper coefficient of the linear link. Defaults to '''0.4'''<br />
* real {{Literal|Friction}} Friction coefficient of the rotational link. Defaults to '''0.4'''<br />
* real {{Literal|Spring}} Spring coefficient of the linear link. Defaults to '''30.0'''<br />
* real {{Literal|Torsion}} Torsion coefficient of the rotational link. Defaults to '''30.0'''<br />
* real {{Literal|Mass}} Mass of the dynamic system. Defaults to '''0.3'''<br />
* real {{Literal|Inertia}} Moment of inertia of the dynamic system. Defaults to '''0.3'''<br />
* bool {{Literal|Spring rigid}} When checked linear spring is rigid. Defaults to '''off'''<br />
* bool {{Literal|Torsion rigid}} When checked torsion spring is rigid. Defaults to '''off'''<br />
* bool {{Literal|Origin drags tip}} When checked result is origin + dynamic tip otherwise result is just dynamic tip. Defaults to '''off'''<br />
<br />
==== Comments ====<br />
<br />
The movement of the Origin produces two effects. It drags the resulting vector the same amount of the Origin along the time (that is the resulting vector is the sum of the Origin(t) + dynamic tip(t)) and its acceleration produces an inertial force contrary to the acceleration direction and magnitude.<br />
<br />
The Torque only affects the angle of the resulting vector respect to the Origin. This means that the mass center of gravity is located at the origin (where the torque is applied) and so there is not centrifugal effects.<br />
<br />
Since the Origin only can be translated and not rotated, there are not Coriolis forces.<br />
<br />
The Force is applied on the tip position so it would produce effects on the angle and on the length of the tip. Force (F) is decomposed into two vectors one aligned with the Tip vector (Fr) and other perpendicular (Fa). The one aligned (Fr) is used on the linear damper spring equations. The one perpendicular (Fa) is used as additional torque by this expression Fr*R (where R is the variable length of the Tip vector)<br />
<br />
If Mass (Inertia) reaches near to zero, then the movement for linear (rotational) link is disabled.<br />
<br />
User is responsible of the meaning of the values of the parameters (i.e. negative mass, or negative friction or spring constant)<br />
<br />
Origin is automatically connected to a subparameter of an internal Value Node in order to calculate the second derivative of the Origin (that is the acceleration of the Origin). '''Do not''' Disconnect Origin value node. Export it instead and link or connect other Value Nodes to the exported.<br />
<br />
=== Dynamic List ===<br />
<br />
Converting a {{l|Convert#List|list}} parameter to {{Literal|Dynamic List}} seems to replace each of the {{Literal|Vertex NNN}} sub-parameters with {{Literal|Item NNN}} parameters which '''can't be expanded''', but can be {{l|export}}ed.<br />
<br />
=== Exponential ===<br />
<br />
Converting a {{l|Convert#Real|real}} parameter to {{Literal|Exponential}} adds two sub-parameters:<br />
<br />
* real "Exponent"<br />
* real "Scale"<br />
<br />
The resulting value is the result raising the [http://en.wikipedia.org/wiki/E_%28mathematical_constant%29 mathematical constant 'e'] to the power of {{Literal|Exponent}}, and scaling the result by {{Literal|Scale}}. That is, it returns:<br />
Scale * e^Exponent<br />
<br />
This is useful for tracking layers which have been zoomed, since the {{l|Zoom Layer}} scales by e^(zoom factor).<br />
<br />
See [http://youtube.com/watch?v=GAWtndOHkUw this video] for an example of the use of this convert type.<br />
<br />
=== From Integer ===<br />
<br />
This is currently disabled. It converts an integer to one of several types.<br />
<br />
=== Gradient Color ===<br />
<br />
Converting a {{l|Convert#Color|color}} parameter to {{Literal|Gradient Color}} adds two sub-parameters:<br />
<br />
* gradient "Gradient"<br />
* real "Index"<br />
<br />
The resulting value is a color taken from the {{l|Gradient Tool}} at the given index position. {{Literal|Index}} '''0''' corresponds to the left of the {{Literal|Gradient}}; {{Literal|Index}} '''1''' corresponds to the right of the {{Literal|Gradient}}.<br />
<br />
=== Gradient Rotate ===<br />
<br />
Converting a {{l|Convert#Gradient|gradient}} parameter to {{Literal|Gradient Rotate}} adds two sub-parameters:<br />
<br />
* gradient "Gradient"<br />
* real "Offset"<br />
<br />
The resulting value is a gradient based on the {{Literal|Gradient}} parameter, but shifted left (for negative values) or right, according to the value of the {{Literal|Offset}} parameter. An offset of '''1.0''' will shift the gradient by its entire visible width. Values shifted off the left or right edge aren't lost - they aren't visible in the gradient as it's displayed in the parameters dialog, but they will still be used when rendering (depending on parameters such as {{Literal|Loop}} and {{Literal|Zigzag}}, which can cause gradients to be looped between their their left and right edges, rather than using the non-displayed parts).<br />
<br />
=== Int String ===<br />
<br />
Converting an {{l|Convert#String|string}}-valued parameter to {{Literal|Int String}} adds three sub-parameters:<br />
* integer "Int"<br />
* integer "Width"<br />
* bool "Zero Padded"<br />
<br />
The resulting value a string containing {{Literal|Int}} formatted as a string with a minimum width {{Literal|Width}}. If {{Literal|Zero Padded}} is '''true''', it will be left-padded with "0" characters.<br />
<br />
=== Joined List ===<br />
<br />
Converting a {{l|Convert#String|string}} parameter to be {{Literal|Joined List}} adds four sub-parameters:<br />
* list "Strings"<br />
* string "Before"<br />
* string "Separator"<br />
* string "After"<br />
<br />
The result is a string containing the value of {{Literal|Before}}, followed by all the strings in the {{Literal|Strings}} list, with the value of {{Literal|Separator}} between each pair, followed by the value of {{Literal|After}}.<br />
<br />
=== Linear ===<br />
<br />
Converting an {{l|Convert#Angle|angle}} parameter to be {{Literal|Linear}} adds two angle sub-parameters:<br />
* angle "Rate"<br />
* angle "Offset"<br />
<br />
Converting a {{l|Convert#Color|color}} parameter to be {{Literal|Linear}} adds two angle sub-parameters (since svn r617):<br />
* color "Rate"<br />
* color "Offset"<br />
<br />
Converting an {{l|Convert#Integer|integer}} parameter to be {{Literal|Linear}} adds two angle sub-parameters (since svn r617):<br />
* integer "Rate"<br />
* integer "Offset"<br />
<br />
Converting a {{l|Convert#Real|real}} parameter to be {{Literal|Linear}} adds two real-valued sub-parameters:<br />
* real "Rate"<br />
* real "Offset"<br />
<br />
Converting a {{l|Convert#Time|time}} parameter to be {{Literal|Linear}} adds two time sub-parameters:<br />
* time "Rate"<br />
* time "Offset"<br />
<br />
Converting a {{l|Convert#Vector|vector}} parameter to be {{Literal|Linear}} adds two vector sub-parameters:<br />
* vector "Slope"<br />
* vector "Offset"<br />
<br />
The parameter's value will change linearly over time, starting with the value specified by {{Literal|Offset}} at time zero, and increasing by the value specified by {{Literal|Rate}} (or {{Literal|Slope}}, in the case of vector parameters) every second.<br />
<br />
The resulting value for vector parameters is:<br />
Offset + Slope*time<br />
<br />
and for the other 5 types of parameter it is:<br />
Offset + Rate*time<br />
<br />
=== Logarithm ===<br />
<br />
Converting a {{l|Convert#Real|real}}-valued parameter to {{Literal|Logarithm}} adds three sub-parameters:<br />
<br />
* real "Link"<br />
* real "Epsilon".<br />
* real "Infinite". <br />
<br />
The resulting value is:<br />
<br />
Log(Link) (if Link >= Epsilon)<br />
-Infinite (if Link < Epsilon)<br />
<br />
The {{Literal|Epsilon}} and {{Literal|Infinite}} parameters are only needed to prevent logarithm of negative or zero numbers. For regular operation the resulting value is simply the natural logarithm of {{Literal|Link}}. In fact a logarithm of a negative number cannot be calculated in the space of Real numbers. This convert type returns -Infinite for simplicity.<br />
<br />
=== Not ===<br />
<br />
Converting a {{l|Convert#Bool|bool}} parameter to {{Literal|Not}} adds one sub-parameter:<br />
* bool "Link"<br />
<br />
The resulting value is the opposite of {{Literal|Link}}.<br />
<br />
=== Or ===<br />
<br />
Converting a {{l|Convert#Bool|bool}} parameter to {{Literal|Or}} adds two sub-parameters:<br />
* bool "Link1"<br />
* bool "Link2"<br />
<br />
The resulting value is true if either {{Literal|Link1}}, {{Literal|Link2}}, or both are '''true'''.<br />
<br />
=== Power ===<br />
<br />
Converting a {{l|Convert#Real|real}}-valued parameter to {{Literal|Power}} adds three sub-parameters:<br />
* real "Base"<br />
* real "Power"<br />
* real "Epsilon".<br />
* real "Infinite".<br />
<br />
The resulting value is Base^Power if the operation is defined.<br />
The undefined cases will also return a value (to avoid errors):<br />
0^0 = 1<br />
0^-x = +/- infinite<br />
If a negative base is raised to a noninteger power, the power is rounded (typecast) to an integer<br />
<br />
The {{Literal|Epsilon}} and {{Literal|Infinite}} parameters are only needed to prevent division by zero.<br />
<br />
=== Radial Composite ===<br />
<br />
Converting a {{l|Convert#Color|color}} to {{Literal|Radial Composite}} adds four sub-parameters:<br />
* real "Luma"<br />
* real "Saturation"<br />
* angle "Hue"<br />
* real "Alpha"<br />
<br />
Converting a {{l|Convert#Vector|vector}} to {{Literal|Radial Composite}} adds two sub-parameters:<br />
* real "Radius"<br />
* angle "Theta"<br />
<br />
For color parameters, the resulting value is the color with the given {{Literal|Luma}}, {{Literal|Saturation}}, {{Literal|Hue}}, and {{Literal|Alpha}} amounts.<br />
<br />
For vector parameters, the resulting value is the point reached by traveling a distance {{Literal|Radius}} from the origin, in the distance given by the angle {{Literal|Theta}}.<br />
<br />
=== Random === <br />
<br />
Converting a parameter to {{Literal|Random}} adds five sub-parameters, the first of which is the same type as the converted parameter:<br />
<br />
* <param> "Link"<br />
* real "Radius"<br />
* integer "Seed"<br />
* real "Animation Speed"<br />
* integer "Interpolation"<br />
* real "Loop Time" (since SVN r2315)<br />
<br />
{{Literal|Random}} can be used on {{l|Convert#Angle|angles}}, {{l|Convert#Color|colors}}, {{l|Convert#Integer|integers}}, {{l|Convert#Real|reals}}, {{l|Convert#Time|times}}, and {{l|Convert#Vector|vectors}}.<br />
<br />
It is used to cause a parameter's value to vary randomly over time, around a central value:<br />
<br />
* {{Literal|Link}} provides the central value.<br />
* {{Literal|Radius}} defines the maximum random difference.<br />
* {{Literal|Seed}} seeds the random number generator<br />
* {{Literal|Animation Speed}} defines how often a new random value is chosen (in choices per second)<br />
* {{Literal|Interpolation}} determines how the value is interpolated from one random choice to the next. Possible values are:<br />
** '''0''' - no interpolation; the value jumps from one value to the next<br />
** '''1''' - linear interpolation<br />
** '''2''' - cosine<br />
** '''3''' - spline<br />
** '''4''' - cubic (the default); uses [http://www.gamedev.net/reference/articles/article1497.asp Catmull-Rom] spline interpolation<br />
* {{Literal|Loop Time}} (added in SVN r2315) makes the random value repeat after the given time. The value ends up the same at the given time as at time=0 so it's possible to make random looping animations without a nasty jump when the time wraps back to zero.<br />
<br />
The {{Literal|Interpolation}} sub-parameter should really be a drop-down menu, rather than an integer field, but that isn't yet implemented.<br />
<br />
=== Range ===<br />
<br />
Converting a parameter to {{Literal|Range}} adds three sub-parameters, all the same type as the parameter itself:<br />
* <param> "Min"<br />
* <param> "Max"<br />
* <param> "Link"<br />
<br />
{{Literal|Range}} can be used on {{l|Convert#Angle|angles}}, {{l|Convert#Integer|integers}}, {{l|Convert#Real|reals}}, and {{l|Convert#Time|times}}.<br />
<br />
It is used to limit the value of the linked parameter to be between {{Literal|Min}} and {{Literal|Max}}.<br />
<br />
The resulting value is:<br />
Min (if Link < Min)<br />
Max (if Link > Max)<br />
Link (otherwise)<br />
<br />
=== Real String ===<br />
<br />
Converting a {{l|Convert#String|string}} parameter to {{Literal|Real String}} adds four sub-parameters:<br />
<br />
* real "Real"<br />
* int "Width"<br />
* int "Precision"<br />
* bool "Zero Padded"<br />
<br />
The result is a string formatted to contain the given value {{Literal|Real}}. {{Literal|Width}} specifies the minimum field width, {{Literal|Precision}} specifies the number of decimal places and {{Literal|Zero Padded}} specifies whether to pad with zeros on the left hand side.<br />
<br />
For example, with Real=3.1415, Width=6, Precision=2, and ZeroPadded=true, we get:<br />
"003.14"<br />
(6 characters long, 2 decimal places, and padded with zeros on the left).<br />
<br />
=== Reciprocal ===<br />
<br />
Converting a {{l|Convert#Real|real}}-valued parameter to {{Literal|Reciprocal}} adds three sub-parameters:<br />
* real "Link"<br />
* real "Epsilon".<br />
* real "Infinite".<br />
<br />
The resulting value is:<br />
1/Link (Link <= -epsilon or epsilon <= Link)<br />
Infinite (if 0 <= Link < epsilon)<br />
-Infinite (if -epsilon < Link < 0)<br />
<br />
The {{Literal|Epsilon}} and {{Literal|Infinite}} parameters are only needed to prevent division by zero. For regular operation the resulting value is simply the reciprocal of {{Literal|Link}}.<br />
<br />
=== Reference ===<br />
<br />
Converting a parameter to {{Literal|Reference}} adds a single sub-parameter called {{Literal|Link}}. The {{Literal|Link}} parameter is the same type as the parameter being converted.<br />
<br />
It doesn't seem to do anything at all, other than adding an extra parameter. Whatever value is put into {{Literal|Link}} becomes the value of the parameter being converted.<br />
<br />
The only use for this conversion type I can think of is the following:<br />
<br />
* you know that point A should follow point B, so you export point B and connect point A to it<br />
* you're not yet sure exactly how point B should move, so you experiment with different conversion types for point B<br />
* changing the conversion type for point B breaks the connection you made in the first step<br />
* converting point B to be a reference, and then experimenting with different conversions in its {{Literal|Link}} parameter allows point A to connect to point B and for the connection to remain in place while you experiment in the {{Literal|Link}} parameter<br />
<br />
The resulting value is:<br />
Link<br />
<br />
=== Repeat Gradient ===<br />
<br />
Converting a {{l|Convert#Gradient|gradient}} parameter to {{Literal|Repeat Gradient}} adds seven sub-parameters:<br />
* gradient "Gradient"<br />
* integer "Count"<br />
* real "Width"<br />
* bool "Specify Start"<br />
* bool "Specify End"<br />
* color "Start Color"<br />
* color "End Color"<br />
<br />
The resulting value is a gradient containing {{Literal|Count}} equally spaced, equally wide copies of {{Literal|Gradient}}. Each copy has {{Literal|Gradient}} going forwards and then backwards. {{Literal|Width}} specifies relative width of the forward copy, with a width of '''0''' or less meaning only the backward copy is used, and a width of '''1''' or more meaning only the forward copy is used. A value of '''0.5''' will result in the forward and reverse copies of {{Literal|Gradient}} being the same width.<br />
<br />
If {{Literal|Specify Start}} is checked then {{Literal|Start Color}} will be inserted at the beginning of the new gradient, otherwise the beginning of {{Literal|Gradient}} will be used as the beginning of the new gradient.<br />
<br />
If {{Literal|Specify End}} is checked then {{Literal|End Color}} will be appended to the end of the new gradient, otherwise the end of {{Literal|Gradient}} will be used as the end of the new gradient.<br />
<br />
Here's an example of a repeated gradient - the radiating green/yellow lines are a repeated gradient, applied to a perpendicular curve gradient. This gradient was repeated with a width of '''0.5''', meaning it is used backwards and forwards the same amount:<br />
<br />
{{l|File:Repeat-gradient-valuenode-gradient.png|frame|center}}<br />
<br />
and here's the resulting image, along with the .sif file:<br />
<br />
{{l|File:Repeat-gradient-valuenode.png|frame|center}}<br />
<br />
You can donwload the project {{l|Media:Repeat-gradient-valuenode.sif}}<br />
<br />
=== Reverse Tangent ===<br />
<br />
Converting a {{l|Convert#Spline Point|Spline Point}} parameter to {{Literal|Reverse Tangent}} adds two sub-parameters: one called {{Literal|Reference}} of type Spline Point, and a boolean parameter called {{Literal|Reverse}}.<br />
* Spline Point "Reference"<br />
* bool "Reverse"<br />
<br />
{{Literal|Reverse Tangent}} can only be used on {{l|Convert#Spline Point|Spline Points}}.<br />
<br />
The resulting value is the same as the {{Literal|Reference}} Spline Point, but with its tangents switched over. This is useful when attempting to link the vertices of a {{l|Region Layer|region}} to the vertices of an {{l|Outline Layer|outline}} when the region and the outline were drawn in opposite directions, and so tangent1 of an outline vertex needs to be linked to tangent2 of the region vertex, and vice versa.<br />
<br />
=== Scale ===<br />
<br />
Converting a parameter to {{Literal|Scale}} adds two sub-parameters: one called {{Literal|Link}}, of the same type as the parameter itself, and a real-valued parameter called {{Literal|Scalar}}.<br />
* <param> "Link"<br />
* real "Scalar"<br />
<br />
{{Literal|Scale}} can be used on {{l|Convert#Angle|angles}}, {{l|Convert#Color|colors}}, {{l|Convert#Integer|integers}}, {{l|Convert#Real|reals}}, {{l|Convert#Time|times}}, and {{l|Convert#Vector|vectors}}.<br />
<br />
The resulting value is:<br />
Link * Scalar<br />
<br />
=== Segment Tangent ===<br />
<br />
Converting a {{l|Convert#Vector|vector}} parameter to {{Literal|Segment Tangent}} adds two sub-parameters:<br />
* segment "Segment"<br />
* real "Amount"<br />
<br />
{{Literal|Amount}} is a number between '''0''' and '''1''', defining the distance along the given {{Literal|Segment}}. The resulting value for the whole parameter is the tangent to the segment, at the given point along the segment.<br />
<br />
=== Segment Vertex ===<br />
<br />
Converting a {{l|Convert#Vector|vector}} parameter to {{Literal|Segment Vertex}} adds two sub-parameters:<br />
* segment "Segment"<br />
* real "Amount" <br />
<br />
{{Literal|Amount}} is a number between '''0''' and '''1''', defining the distance along the given {{Literal|Segment}}. The resulting value is the vertex at the given point along the segment.<br />
<br />
=== Sine ===<br />
<br />
Converting a {{l|Convert#Real|real}}-valued parameter to {{Literal|Sine}} adds two sub-parameters:<br />
* angle "Angle"<br />
* real "Amplitude".<br />
<br />
The resulting value is:<br />
Amplitude * sin(Angle)<br />
<br />
=== Spline Tangent ===<br />
<br />
Converting a {{l|Convert#Angle|angle}}, {{l|Convert#Real|real}} (since SVN r1862), or {{l|Convert#Vector|vector}} parameter to {{Literal|Spline Tangent}} adds six sub-parameters:<br />
* spline "Spline"<br />
* bool "Loop"<br />
* real "Amount"<br />
* angle "Offset" (since SVN r1863)<br />
* real "Scale" (since SVN r1863)<br />
* bool "Fixed Length" (since SVN r1863)<br />
<br />
{{Literal|Amount}} is a number between '''0''' and '''1''', defining the distance along the given spline. The resulting value for the whole parameter is the tangent to the spline, at the given point along the spline, optionally rotated and scaled according to the {{Literal|Offset}}, {{Literal|Scale}}, and {{Literal|Fixed Length}} parameters.<br />
<br />
{{Literal|Offset}} is an angle used to give the tangent an extra rotation before returning it. If {{Literal|Fixed Length}} is '''true''', the tangent is then scaled to have a length equal to {{Literal|Scale}}. Otherwise the tangent is multiplied by {{Literal|Scale}}.<br />
<br />
If a vector was converted the result is the tangent itself. If an angle was converted, the result is the angle of the tangent to the horizontal, and if a real was converted, the result is the length of the tangent.<br />
<br />
This {{l|Following a Spline|tutorial}} gives an example of the use of this convert type.<br />
<br />
=== Spline Vertex ===<br />
<br />
Converting a {{l|Convert#Vector|vector}} parameter to {{Literal|Spline Vertex}} adds three sub-parameters:<br />
* spline "Spline"<br />
* bool "Loop"<br />
* real "Amount"<br />
<br />
{{Literal|Amount}} is a number between '''0''' and '''1''', defining the distance along the given spline. The resulting value for the whole parameter is a vector giving the position of the given point along the spline.<br />
<br />
This {{l|Following a Spline|tutorial}} gives an example of the use of this convert type.<br />
<br />
=== Spline Width ===<br />
<br />
Converting a {{l|Convert#Real|real}} parameter to {{Literal|Spline Width}} adds three sub-parameters:<br />
* spline "Spline"<br />
* bool "Loop"<br />
* real "Amount"<br />
* real "Scale" (since SVN r1872)<br />
<br />
{{Literal|Amount}} is a number between '''0''' and '''1''', defining the distance along the given spline. The resulting value for the whole parameter is the width of the spline at the given point along it, multiplied by the {{Literal|Scale}} parameter.<br />
<br />
=== Step ===<br />
<br />
Converting an {{l|Convert#Angle|angle}}, {{l|Convert#Color|color}}, {{l|Convert#Integer|integer}}, {{l|Convert#Real|real}}, {{l|Convert#Time|time}}, or {{l|Convert#Vector|vector}} parameter to be {{Literal|Step}} adds four sub-parameters:<br />
* <param> "Link"<br />
* time "Duration"<br />
* time "Start Time"<br />
* real "Intersection"<br />
<br />
The parameter's value will change in steps. Each step is {{Literal|Duration}} seconds long. The steps start at times {{Literal|Start Time}}, {{Literal|Start Time}}+{{Literal|Duration}}, etc. The value of the valuenode is the value of {{Literal|Link}} at some time. {{Literal|Intersection}} determines which time is used. An {{Literal|Intersection}} of '''0.0''' means that the value of {{Literal|Link}} at the start of the step should be used. An {{Literal|Intersection}} of '''0.5''' (the default) means to use the value of {{Literal|Link}} at the middle of the step, etc.<br />
<br />
The resulting value at time <math>T</math> is:<br />
<math>Link \Bigg ( \Bigg ( Duration \cdot \left ( \left \lfloor \frac{T - Start\ Time}{Duration} \right \rfloor + Intersection \right ) \Bigg ) + Start \ Time \Bigg )</math><br />
<br />
==== Example ====<br />
<br />
{{Literal|Link}} is a sine wave. {{Literal|Duration}} is '''10f''' (the frame rate is 24 fps). {{Literal|Start Time}} is '''1s'''.<br />
<br />
So one step starts at '''1s''', and others start at '''0s 14f''', '''0s 4f''', '''1s 10f''', etc.<br />
<br />
This is the (kind of) sine wave:<br />
<br />
{{l|File:Convert Smooth-sine 0.63.06.png|frame|center}}<br />
<br />
And this is the effect of the Step valuenode on it, with an {{Literal|Intersection}} of '''0.0'''. Notice that at time '''0s''', the step has a negative value -- that step runs from '''-6f''' to '''4f''', and so its value is the value of {{Literal|Link}} at time '''-6f'''. ''These images were created in [http://www.gimp.org/ The Gimp] - it's not currently possible to view two curves at the same time in Synfig Studio.''<br />
<br />
{{l|File:Convert Stepped-sine 0.0 0.63.06.png|frame|center}}<br />
<br />
Here it is with an {{Literal|Intersection}} of '''0.5''':<br />
<br />
{{l|File:Convert Stepped-sine 0.5 0.63.06.png|frame|center}}<br />
<br />
and here, with an {{Literal|Intersection}} '''of 1.0''':<br />
<br />
{{l|File:Convert Stepped-sine 1.0 0.63.06.png|frame|center}}<br />
<br />
You can download the project {{l|Media:Doc Convert Step.sifz}}<br />
<br />
=== Stripes ===<br />
<br />
Converting a {{l|Convert#Gradient|gradient}} parameter to {{Literal|Stripes}} adds four sub-parameters:<br />
* color "Color 1"<br />
* color "Color 2"<br />
* integer "Stripe Count"<br />
* real "Width"<br />
<br />
The resulting value is a gradient containing {{Literal|Stripe Count}} equally spaced, equally wide stripes of color {{Literal|Color 2}} with a background of {{Literal|Color 1}}. {{Literal|Width}} specifies the width of the stripes, with a {{Literal|Width}} of '''0''' or less meaning they are invisible, and a {{Literal|Width}} of '''1''' or more meaning the whole gradient is of {{Literal|Color 2}}.<br />
<br />
=== Subtract ===<br />
<br />
Converting a parameter to {{Literal|Subtract}} adds three sub-parameters, the first two of which are the same type as the parameter itself:<br />
* <param> "LHS"<br />
* <param> "RHS"<br />
* real "Scalar"<br />
<br />
The {{Literal|Subtract}} conversion can be used with parameters of type {{l|Convert#Angle|angle}}, {{l|Convert#Color|color}}, {{l|Convert#Gradient|gradient}}, {{l|Convert#Integer|integer}}, {{l|Convert#Real|real}}, {{l|Convert#Time|time}}, and {{l|Convert#Vector|vector}}.<br />
<br />
The resulting value is:<br />
(LHS - RHS) * Scalar<br />
<br />
=== Switch ===<br />
<br />
Converting a parameter to {{Literal|Switch}} adds three sub-parameters:<br />
* <param> "Link Off"<br />
* <param> "Link On"<br />
* bool "Switch"<br />
<br />
{{Literal|Link Off}} and {{Literal|Link On}} are the same type as the parameter being converted.<br />
<br />
The resulting value is the value of {{Literal|Link Off}} when {{Literal|Switch}} is '''off''', and {{Literal|Link On}} when {{Literal|Switch}} is '''on'''.<br />
<br />
This conversion can be used on all value types.<br />
<br />
=== Time Loop ===<br />
<br />
Converting a parameter to {{Literal|Time Loop}} adds four sub-parameters: one called {{Literal|Link}}, of the same type as the parameter itself, and three time parameters:<br />
<br />
* <param> "Link"<br />
* time "Link Time" <br />
* time "Local Time"<br />
* time "Duration"<br />
<br />
It works similarly to the {{l|Time Loop Layer}} but affects only a single parameter.<br />
<br />
For any integer value '''n''', from "Local Time + abs(Duration)*n" to "Local Time + abs(Duration)*(n+1)", the resulting value of the parameter is the same as that of the {{Literal|Link}} parameter from {{Literal|Link Time}} to "Link Time + Duration".<br />
<br />
In other words, {{Literal|Duration}} seconds of values of the parameter {{Literal|Link}} starting from time {{Literal|Link Time}} onwards are looped over and over, with the value of the {{Literal|Link}} parameter at time {{Literal|Link Time}} corresponding to the resulting value at time {{Literal|Local Time}}.<br />
<br />
As an example, suppose the {{Literal|Link}} parameter has a value of time the current time. At '''0s''' the value is '''0''', at '''10s''' the value is '''20'''.<br />
<br />
If we set:<br />
* Link Time = 5s<br />
* Local Time = 2s<br />
* Duration = 4s<br />
then from '''2s''' to '''6s''' and from '''6s''' to '''10s''', etc., the resulting value is the value of {{Literal|Link}} from '''5s''' to '''9s''', as follows:<br />
<br />
Then the resulting values will be:<br />
* 0s -> "Link" value at 7s = 14<br />
* 1s -> "Link" value at 8s = 16<br />
* 2s -> "Link" value at 5s = 10 (at "Link Time" = 2s, result is the value of "Link" at "Link Time" = 5s = 10)<br />
* 3s -> "Link" value at 6s = 12<br />
* 4s -> "Link" value at 7s = 14<br />
* 5s -> "Link" value at 8s = 16<br />
* 6s -> "Link" value at 5s = 10 ("Duration" = 4s later, the value is the same as at 2s)<br />
* 7s -> "Link" value at 6s = 12<br />
<br />
If {{Literal|Duration}} is '''zero''', the resulting value is whatever the value of the {{Literal|Link}} parameter is at time {{Literal|Link Time}}.<br />
<br />
If {{Literal|Duration}} is negative, the resulting value at {{Literal|Local Time}} still matches the value of {{Literal|Link}} at {{Literal|Link Time}}, but the animation goes in the opposite direction. For example:<br />
<br />
If we set:<br />
* Link Time = 5s<br />
* Local Time = 2s<br />
* Duration = -4s<br />
then from '''2s''' to '''6s''' and from '''6s''' to '''10s''', etc., the resulting value is the value of {{Literal|Link}} from '''5s''' to '''1s''', as follows:<br />
<br />
Then the resulting values will be:<br />
* 0s -> "Link" value at 3s = 6<br />
* 1s -> "Link" value at 2s = 4<br />
* 2s -> "Link" value at 5s = 10 (at "Link Time" = 2s, result is the value of "Link" at "Link Time" = 5s = 10)<br />
* 3s -> "Link" value at 4s = 8<br />
* 4s -> "Link" value at 3s = 6<br />
* 5s -> "Link" value at 2s = 4<br />
* 6s -> "Link" value at 5s = 10 (4s later, the value is the same as at "Link Time" = 2s)<br />
* 7s -> "Link" value at 4s = 8<br />
<br />
This conversion can be used on all value types.<br />
<br />
=== Time String ===<br />
<br />
Converting a {{l|Convert#String|string}} parameter to {{Literal|Time String}} adds one sub-parameter called {{Literal|Time}}, of type time:<br />
<br />
* time "Time" <br />
<br />
The result is a string containing the given {{Literal|Time}}.<br />
<br />
=== Timed Swap ===<br />
<br />
This convert type was disabled in Synfig 0.61.06 and earlier because it didn't work.<br />
<br />
Converting a parameter to {{Literal|Timed Swap}} adds four sub-parameters:<br />
* <param> "Before"<br />
* <param> "After"<br />
* time "Swap Time"<br />
* time "Swap Duration"<br />
<br />
{{Literal|Before}} and {{Literal|After}} are the same type as the parameter being converted.<br />
<br />
This conversion type linearly switches from {{Literal|Before}} to {{Literal|After}}, taking {{Literal|Swap Duration}} seconds to do so, and completing the swap at {{Literal|Swap Time}}.<br />
<br />
Note that this doesn't give us anything that we can't achieve using the "{{l|Convert#Linear|Linear}}" conversion type and a few {{l|Waypoint|waypoints}}.<br />
<br />
{{Literal|Timed Swap}} can be used on {{l|Convert#Angle|angles}}, {{l|Convert#Color|colors}}, {{l|Convert#Integer|integers}}, {{l|Convert#Real|reals}}, {{l|Convert#Time|times}}, and {{l|Convert#Vector|vectors}}.<br />
<br />
The resulting value is:<br />
if time > "Swap Time" then "After"<br />
else if time < ("Swap Time" - "Swap Duration") then "Before"<br />
else interpolate between "Before" and "After"<br />
<br />
=== Two-Tone ===<br />
<br />
Converting a {{l|Convert#Gradient|gradient}} to {{Literal|Two-Tone}} adds two color-valued sub-parameters:<br />
* color "Color1"<br />
* color "Color2"<br />
<br />
The resulting gradient has two {{l|Color Stop}}, one at each end, starting with {{Literal|Color1}} and ending with {{Literal|Color2}}.<br />
<br />
These color parameters can be animated, giving us the ability to have the gradient change color over time. It used to be used as a workaround for [http://sourceforge.net/tracker/index.php?func=detail&aid=1568818&group_id=144022&atid=757416 this bug].<br />
<br />
=== Vector Angle ===<br />
<br />
Converting an {{l|Convert#Angle|angle}} to {{Literal|Vector Angle}} adds a vector sub-parameter:<br />
* vector "Vector"<br />
<br />
The resulting value is the angle between the {{Literal|Vector}} and the X axis.<br />
<br />
=== Vector Length ===<br />
<br />
Converting a {{l|Convert#Real|real}} to {{Literal|Vector Length}} adds a vector sub-parameter:<br />
* vector "Vector"<br />
<br />
The resulting value is the length of the {{Literal|Vector}}.<br />
<br />
=== Vector X ===<br />
<br />
Converting a {{l|Convert#Real|real}} to {{Literal|Vector X}} adds a vector sub-parameter:<br />
* vector "Vector"<br />
<br />
The resulting value is the X component of the {{Literal|Vector}}.<br />
<br />
=== Vector Y ===<br />
<br />
Converting a {{l|Convert#Real|real}} to {{Literal|Vector Y}} adds a vector sub-parameter:<br />
* vector "Vector"<br />
<br />
The resulting value is the Y component of the {{Literal|Vector}}.<br />
<br />
== Which Value Types can use which Convert Types? ==<br />
<br />
There are 13 different types of value in Synfig. Each of these types has a different set of convert types available to it, as follows:<br />
<br />
=== {{l|Image:type_angle_icon.png|22px}} Angle ===<br />
<br />
Angle parameters can be converted to {{l|Convert#Add|Add}}, {{l|Convert#aTan2|aTan2}}, {{l|Convert#Spline Tangent|Spline Tangent}}, {{l|Convert#Dot Product|Dot Product}}, {{l|Convert#Linear|Linear}}, {{l|Convert#Random|Random}}, {{l|Convert#Range|Range}}, {{l|Convert#Scale|Scale}}, {{l|Convert#Step|Step}}, {{l|Convert#Subtract|Subtract}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Timed Swap|Timed Swap}}, {{l|Convert#Vector Angle|Vector Angle}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_bool_icon.png|22px}} Bool ===<br />
<br />
Bool parameters can only be converted to the {{l|Convert#And|And}}, {{l|Convert#Greyed|Greyed}}, {{l|Convert#Or|Or}}, {{l|Convert#Not|Not}}, {{l|Convert#Compare|Compare}} {{l|Convert#Random|Random}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}},and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:Type canvas icon 0.63.06.png|22px}} Canvas ===<br />
<br />
Canvas parameters can be converted to the {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, and {{l|Convert#Reference|Reference}} type.<br />
<br />
=== {{l|Image:type_color_icon.png|22px}} Color ===<br />
<br />
Color parameters can be converted to {{l|Convert#Add|Add}}, {{l|Convert#Composite|Composite}}, {{l|Convert#Gradient Color|Gradient Color}}, {{l|Convert#Linear|Linear}}, {{l|Convert#Radial Composite|Radial Composite}}, {{l|Convert#Random|Random}}, {{l|Convert#Scale|Scale}}, {{l|Convert#Step|Step}}, {{l|Convert#Subtract|Subtract}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Timed Swap|Timed Swap}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_gradient_icon.png|22px}} Gradient ===<br />
<br />
Gradient parameters can be converted to {{l|Convert#Add|Add}}, {{l|Convert#Gradient Rotate|Gradient Rotate}}, {{l|Convert#Repeat Gradient|Repeat Gradient}}, {{l|Convert#Stripes|Stripes}}, {{l|Convert#Subtract|Subtract}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Two-Tone|Two-Tone}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_integer_icon.png|22px}} Integer ===<br />
<br />
Integer parameters can be converted to {{l|Convert#Add|Add}}, {{l|Convert#Linear|Linear}}, {{l|Convert#Random|Random}}, {{l|Convert#Range|Range}}, {{l|Convert#Scale|Scale}}, {{l|Convert#Step|Step}}, {{l|Convert#Subtract|Subtract}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Timed Swap|Timed Swap}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_list_icon.png|22px}} List ===<br />
<br />
List parameters can be converted to {{l|Convert#Spline|Spline}}, {{l|Convert#Dynamic List|Dynamic List}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_real_icon.png|22px}} Real ===<br />
<br />
Real parameters can be converted to {{l|Convert#Add|Add}}, {{l|Convert#Spline Width|Spline Width}}, {{l|Convert#Cos|Cos}}, {{l|Convert#Dot Product|Dot Product}}, {{l|Convert#Exponential|Exponential}}, {{l|Convert#Linear|Linear}}, {{l|Convert#Logarithm|Logarithm}}, {{l|Convert#Power|Power}}, {{l|Convert#Random|Random}}, {{l|Convert#Range|Range}}, {{l|Convert#Reciprocal|Reciprocal}}, {{l|Convert#Scale|Scale}}, {{l|Convert#Sine|Sine}}, {{l|Convert#Step|Step}}, {{l|Convert#Subtract|Subtract}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Timed Swap|Timed Swap}}, {{l|Convert#Vector Length|Vector Length}}, {{l|Convert#Vector X|Vector X}}, {{l|Convert#Vector Y|Vector Y}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_segment_icon.png|22px}} Segment ===<br />
<br />
Segment parameters can be converted to the {{l|Convert#Composite|Composite}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_blinepoint_icon.png|22px}} Spline Point ===<br />
<br />
Spline Point parameters can be converted to {{l|Convert#Composite|Composite}}, {{l|Convert#Reverse Tangent|Reverse Tangent}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
<br />
=== {{l|Image:type_string_icon.png|22px}} String ===<br />
<br />
String parameters can be converted to the {{l|Convert#Angle String|Angle String}}, {{l|Convert#Int String|Int String}}, {{l|Convert#Joined List|Joined List}}, {{l|Convert#Real String|Real String}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Time String|Time String}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_time_icon.png|22px}} Time ===<br />
<br />
Time parameters can be converted to the {{l|Convert#Add|Add}}, {{l|Convert#Linear|Linear}}, {{l|Convert#Random|Random}}, {{l|Convert#Range|Range}}, {{l|Convert#Scale|Scale}}, {{l|Convert#Step|Step}}, {{l|Convert#Subtract|Subtract}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Timed Swap|Timed Swap}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
=== {{l|Image:type_vector_icon.png|22px}} Vector ===<br />
<br />
Vector parameters can be converted to {{l|Convert#Add|Add}}, {{l|Convert#Spline Tangent|Spline Tangent}}, {{l|Convert#Spline Vertex|Spline Vertex}}, {{l|Convert#Composite|Composite}}, {{l|Convert#Linear|Linear}}, {{l|Convert#Radial Composite|Radial Composite}}, {{l|Convert#Random|Random}}, {{l|Convert#Scale|Scale}}, {{l|Convert#Segment Tangent|Segment Tangent}}, {{l|Convert#Segment Vertex|Segment Vertex}}, {{l|Convert#Step|Step}}, {{l|Convert#Subtract|Subtract}}, {{l|Convert#Switch|Switch}}, {{l|Convert#Time Loop|Time Loop}}, {{l|Convert#Timed Swap|Timed Swap}}, and {{l|Convert#Reference|Reference}} types.<br />
<br />
== Compatibility ==<br />
<br />
When a new ValueNode type is added to Synfig, the .sif file format is extended to include a way of writing the new type. This extension won't be able to be read by any older version of Synfig. Here's a list of the ValueNode types that have been added, along with the subversion revision number in which they first appeared:<br />
<br />
<blockquote><br />
{| style="width:55%"<br />
| '''Version''' || '''Revision''' || '''Convert'''<br />
|-<br />
| <hr> || <hr> || <hr><br />
|-<br />
| '''(0.65.0)''' || not yet released || &nbsp;<br />
|-<br />
| &nbsp; || [https://github.com/synfig/synfig/pull/105 pull#105] || {{l|#Dynamic|Dynamic}}<br />
|-<br />
| '''(0.63.06)''' || || &nbsp;<br />
|-<br />
| &nbsp; || ? || BLine Width renamed {{l|#Spline Width|Spline Width}}<br />
|-<br />
| &nbsp; || ? || BLine Vertex renamed {{l|#Spline Vertex|Spline Vertex}}<br />
|-<br />
| &nbsp; || ? || BLine Tangent renamed {{l|#Spline Tangent|Spline Tangent}}<br />
|-<br />
| <hr> || <hr> || <hr><br />
|-<br />
| '''(0.61.09)''' || || &nbsp;<br />
|-<br />
| &nbsp; || 2034 || {{l|#Logarithm|Logarithm}}<br />
|-<br />
| &nbsp; || 2010 || {{l|#Int String|Int String}}<br />
|-<br />
| &nbsp; || 2010 || {{l|#Angle String|Angle String}}<br />
|-<br />
| &nbsp; || 2007 || {{l|#Joined List|Joined List}}<br />
|-<br />
| &nbsp; || 2003 || {{l|#Real String|Real String}}<br />
|-<br />
| &nbsp; || 2000 || {{l|#Time String|Time String}}<br />
|-<br />
| &nbsp; || 1891 || {{l|#Dot Product|Dot Product}}<br />
|-<br />
| &nbsp; || 1885 || {{l|#Gradient Color|Gradient Color}}<br />
|-<br />
| &nbsp; || 1882 || {{l|#Vector X|Vector X}}<br />
|-<br />
| &nbsp; || 1882 || {{l|#Vector Y|Vector Y}}<br />
|-<br />
| &nbsp; || 1881 || {{l|#Vector Length|Vector Length}}<br />
|-<br />
| &nbsp; || 1880 || {{l|#Vector Angle|Vector Angle}}<br />
|-<br />
| <hr> || <hr> || <hr><br />
|-<br />
| '''(0.61.08)''' || 1839 || &nbsp;<br />
|-<br />
| &nbsp; || 1694 || {{l|#Spline Width|BLine Width}}<br />
|-<br />
| &nbsp; || 1690 || {{l|#Random|Random}} (for bools)<br />
|-<br />
| &nbsp; || 1691 || {{l|#Step|Step}}<br />
|-<br />
| &nbsp; || 1354 || {{l|#Subtract|Subtract}} (for gradients)<br />
|-<br />
| &nbsp; || 1354 || {{l|#Add|Add}} (for gradients)<br />
|-<br />
| &nbsp; || 1267 || {{l|#From Integer|From Integer}}<br />
|-<br />
| &nbsp; || 1267 || {{l|#Duplicate|Duplicate}}<br />
|-<br />
| &nbsp; || 1238 || {{l|#Reciprocal|Reciprocal}}<br />
|-<br />
| &nbsp; || 1226 || {{l|#Time Loop|Time Loop}}<br />
|-<br />
| &nbsp; || 1162 || {{l|#Reverse Tangent|Reverse Tangent}}<br />
|-<br />
| &nbsp; || 1132 || {{l|#aTan2|aTan2}}<br />
|-<br />
| &nbsp; || 1111 || {{l|#Cos|Cos}}<br />
|-<br />
| &nbsp; || 923 || {{l|#Switch|Switch}}<br />
|-<br />
| &nbsp; || 907 || {{l|#Random|Random}}<br />
|-<br />
| <hr> || <hr> || <hr><br />
|-<br />
| '''(0.61.07)''' || 878 || &nbsp;<br />
|-<br />
| &nbsp; || 776 || {{l|#Range|Range}}<br />
|-<br />
| &nbsp; || 744 || {{l|#BLine Vertex|Spline Vertex}}<br />
|-<br />
| &nbsp; || 744 || {{l|#BLine Tangent|Spline Tangent}}<br />
|-<br />
| &nbsp; || 742 || {{l|#Add|Add}}<br />
|-<br />
| &nbsp; || 739 || {{l|#Exponential|Exponential}}<br />
|-<br />
| &nbsp; || 666 || {{l|#Repeat Gradient|Repeat Gradient}}<br />
|-<br />
| &nbsp; || 610 || {{l|#Timed Swap|Timed Swap}}<br />
|-<br />
| <hr> || <hr> || <hr><br />
|-<br />
| '''(0.61.06)''' || 536 || &nbsp;<br />
|-|}<br />
</blockquote></div>Ciaranhttps://www.wiki.synfig.org/index.php?title=User_Documentation&diff=19979User Documentation2015-01-02T11:46:05Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>NOTE: The rule is simple: ALL the documentation pages have to be listed here.<br />
<br />
* '''{{l|Category:Manual|Manual}}'''<br />
<DPL><br />
titlematch=Manual<br />
namespace=Category<br />
includepage = *<br />
format = <ul>\n,,,<ul><br />
</DPL><br />
* '''{{l|Category:Tutorials|Tutorials}}'''<br />
<DPL><br />
titlematch=Tutorials<br />
namespace=Category<br />
includepage = *<br />
format = <ul>\n,,,<ul><br />
</DPL><br />
* '''{{l|Category:Reference|Reference}}'''<br />
<DPL><br />
titlematch=Reference<br />
namespace=Category<br />
includepage = *<br />
format = <ul>\n,,,<ul><br />
</DPL><br />
* '''{{l|Category:Glossary|Glossary}}'''<br />
<DPL><br />
titlematch=Glossary<br />
namespace=Category<br />
includepage = *<br />
format = <ul>\n,,,<ul><br />
</DPL></div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Screenshots&diff=19978Screenshots2015-01-02T11:45:26Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>== Voria ==<br />
Screenshots from when synfig was a proprietary product developed by {{l|History|Voria Studios}}.<br />
<br />
{|<br />
|-<br />
| align="center"|<br />
{{l|image:linuxscreenshot.png|320 px|Linux screenshot}}<br />
<br />
GNU/Linux<br />
<br />
| align="center"|<br />
{{l|image:Synfig-MacOSX.png|320 px|Mac OSX}}<br />
<br />
Mac OS X<br />
|}<br />
<br />
== Community ==<br />
;Add your favourite synfig screenshot here!!<br />
<br />
{{l|Image:Screenshot-Linux-06108-2030-1.jpg|320px}}<br />
<br />
Synfig 0.61.08 (2030) running in ArchLinux GNU/Linux distribution, in a KDE desktop.<br />
<br />
{{l|Image:Vista_screenshot.png|320 px|Vista}}<br />
<br />
Microsoft Windows Vista Ultimate Screenshot (With Task Manager showing 'Set Affinity' option. Set it to single CPU for best results)<br />
<br />
{{l|Image:Vista-Synfigstudio-0.61.09.png|320 px|Vista}}<br />
<br />
This is a screenshot in Windows Vista Home Premium in a Dual core HP laptop. <br />
<br />
{{l|Image:XPScreenshot.jpg|320 px|XP}}<br />
<br />
Here is a synfig screenshot in Windows XP exporting the Voria logo.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Canvas_Menu_Caret&diff=19977Canvas Menu Caret2015-01-02T11:45:10Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>{{Title|Canvas Menu Caret}}<br />
{{Category|Canvas Window}}<br />
<br />
{{NewTerminology}}<br />
<br />
Whereas most graphics apps have a set of menus at the top of the screen, the top of the [http://en.wikipedia.org/wiki/Multiple_document_interface MDI] window, or the top of the drawing window, Synfig has a '''Caret'''. A sideways one. It is located in the upper left hand corner of the {{l|Category:Canvas Window}}, and looks like this:<br />
<br />
{{l|File:Menu Caret 0.63.06.png|frame|none}}<br />
<br />
Beneath this button are all the {{l|Category:Canvas Window Menu|menus}} you would expect, from which you can access most of Synfig Studio's features:<br />
<br />
{{l|File:Menu Caret-1 0.63.06.png|frame|none}}</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Render_options&diff=19976Render options2015-01-02T11:44:32Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Render options}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
<br />
== Intro to render ==<br />
<br />
Rendering an animation in Synfig can be done in two way, by the {{l|Doc:Synfig CLI Syntax|Command Line Interface (CLI)}} or through the {{l|Render dialog}}<br />
<br />
== Target ==<br />
<br />
Here are the file {{l|Render dialog|Target}} that can be rendered<br />
<br />
*{{Literal|bmp}} - Bitmap<br />
*{{Literal|cairopng}} - portable Network graphics - images with lossless compression rendered by cairo library<br />
*{{Literal|dv}} - digital video<br />
*{{Literal|ffmpeg}} - TODO writeme<br />
*{{Literal|gif}} - graphic interchange format<br />
*{{Literal|imagemagick}} - image manipulation program<br />
*{{Literal|jpeg}} - Joint Photographic Expert Group - still format suited to photographs<br />
*{{Literal|magick++}} - TODO writeme<br />
*{{Literal|null}} - Dummy file for rendering engine testing?<br />
*{{Literal|null-tile}} - Dummy file for rendering engine testing?<br />
*{{Literal|png}} - portable Network graphics - still images with lossless compression<br />
*{{Literal|ppm}} - portable pixmap - still image using very basic format<br />
*{{Literal|yuv420p}} - Still image format designed to preserve the images luminance<br />
<br />
== Results ==<br />
<br />
{| border="1"<br />
|-<br />
! Target type<br />
! Extension<br />
! Helper app<br />
! width = "180"| <br />
Linux support<br />
! width = "180"|<br />
Windows support<br />
! width = "180"|<br />
Mac OSX support<br />
|-<br />
! Auto<br />
! align = "left" |<br />
*.bmp->bmp<br />
*.dv->dv_trgt<br />
*.mpg->ffmpeg_trg<br />
*.gif->gif<br />
*.miff->imagemagick_trgt<br />
*.jpg->jpeg_trgt<br />
*.avi->Target_LibAVCodec<br />
*.mng->mng_trgt<br />
*.exr->exr_trgt<br />
*.png->png_trgt<br />
*.ppm->ppm<br />
*.yuv->yuv<br />
! Determined by extension<br />
! align = "left" width = "180"|<br />
*.bmp->bmp OK (but text layers upside down) {{l|#note 5 - bug in .bmp (fixed in svn)|5}}<br />
*.dv->dv OK <br />
*.mpg->mpg OK<br />
*.gif->gif OK<br />
*.miff->OK (only last frame?)<br />
*.jpg->jpg OK<br />
*.avi->crash {{l|#note 1 - libav crashes for genete|1}} <br />
*.mng-> not render {{l|#note 3 - mng not working?|3}}<br />
*.exr->exr OK<br />
*.png->png OK<br />
*.ppm->ppm OK<br />
*.yuv->yuv OK? {{l|#note 2 - wtf is yuv?|2}}<br />
! width = "180"|<br />
*.bmp-ok (text layer correct in 983)<br />
*.dv- n/a<br />
*.mpg-crash synfig<br />
*.gif-ok, (imagemagick)animated gif crashes (983)<br />
*.miff-single frame ok, animated crash synfig (983)<br />
*.jpg-ok<br />
*.avi- n/a<br />
*.mng- n/a<br />
*.exr-ok<br />
*.png-ok<br />
*.ppm-ok<br />
*yuv-ok {{l|#note 2 - wtf is yuv?|2}}<br />
! align = "left" width = "180"|<br />
*.bmp-ok, but text layers upside down {{l|#note 5 - bug in .bmp (fixed in svn)|5}}<br />
*.dv-crash synfig<br />
*.mpg-crash synfig<br />
*.gif-ok, also animated gif<br />
*.miff-crash synfig<br />
*.jpg-ok<br />
*.avi-crash synfig<br />
*.mng-"unable to create target for...<br />
*.mov-"unable to create target for...<br />
*.exr-"unable to create target for...<br />
*.png-ok<br />
*.ppm-ok<br />
*yuv-render a file in unknown format<br />
|-<br />
! bmp<br />
! bmp<br />
! Native<br />
! Yes (but text layers upside down) {{l|#note 5 - bug in .bmp (fixed in svn)|5}}<br />
! Yes (Text layers correct in 983)<br />
! ok, but text layers upside down {{l|#note 5 - bug in .bmp (fixed in svn)|5}}<br />
|-<br />
! dv<br />
! dv<br />
! encodedv<br />
! Yes<br />
! N/A - encodedv not supported under Windows<br />
! crash synfig<br />
|-<br />
! ffmpeg<br />
! mpg<br />
! ffmpeg<br />
! width = "180"|<br />
It renders .mpg .avi, .mov and .flv<br />
! width = "180"|<br />
Working with FFMpeg 10464 and SVN 934 (may crash on longer renders)<br />
! width = "180"|<br />
crash synfig<br />
|-<br />
! gif<br />
! gif<br />
! native<br />
! width = "180"|<br />
yes (animated gifs also)<br />
! width = "180"|<br />
yes (animated gifs also)<br />
! width = "180"|<br />
ok<br />
|-<br />
! imagemagick<br />
! miff<br />
! imagemagick<br />
! width = "180"|<br />
yes (but only last frame?)<br />
! width = "180"|<br />
Renders to a readable file, but the image is corrupted in builds prior to SVN 934. Working in 934 and later (October 17th 2007). <br />
! width = "180"|<br />
crash synfig<br />
|-<br />
! magick++<br />
! gif<br />
! native<br />
! width = "180"|<br />
yes (animated gifs, optimized)<br />
! width = "180"|<br />
unknown<br />
! width = "180"|<br />
unknown<br />
|-<br />
! jpeg<br />
! jpg<br />
! native<br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
ok<br />
|-<br />
!libav<br />
!avi<br />
!libavcodec<br />
! yes, tested on Ubuntu Feisty (fails on Ubuntu Edgy)<br />
! N/A - libav support not compiled into the Windows version.<br />
!?<br />
|-<br />
! null<br />
! n/a<br />
! n/a<br />
! n/a<br />
! n/a<br />
! n/a<br />
|-<br />
! null-tile<br />
! n/a<br />
! n/a<br />
! n/a<br />
! n/a<br />
! n/a<br />
|-<br />
! open-exr<br />
! exr<br />
! native<br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
n/a<br />
|-<br />
! png<br />
! png<br />
! native*.mpg-><br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
ok<br />
|- <br />
! ppm<br />
! ppm<br />
! native<br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
yes<br />
! width = "180"|<br />
ok<br />
|- <br />
! yuv420p<br />
! yuv<br />
! native<br />
! width = "180"|<br />
yes but format in unknown format<br />
! width = "180"|<br />
yes but format in unknown format<br />
(use: ffmpeg -i your_yuv420p_file -sameq your_mpg_file.mpg)<br />
! width = "180"|<br />
render file in unknown format<br />
|}<br />
<br />
== Rendering to Video ==<br />
<br />
Rendering to video directly from Synfig under Windows Operating Systems presents some challenges. <br />
<br />
If you want to render to anything other than .mpg with {{Literal|ffmpeg}}, you'll want to save a series of images that represent your animation, to a still format that ffmpeg can read. I recommend {{Literal|png}}. Whilst you can render to any size image, if you're going to show your video on Youtube*.mpg->, you may want to take that into account when you render. <br />
<br />
If you set up your render like {{l|File:Render 0.63.06.png|frame|none}}<br />
<br />
{{literal|Image Size}}<br />
* Width 320 Xres 72.0 Physical width 4.44<br />
* Height 240 Yres 72.0 Physical Height 3.33<br />
* Image span 10.0000<br />
{{literal|Image Area}}<br />
* Top left X : -4 Y : 3 <br />
* Bottom right X : 4 Y : -3<br />
<br />
You will get a series of .png files in your output directory. Open a command prompt, cd to that directory, then use ffmpeg to assemble these png files into the video stream of your choice. for example - <br />
<br />
<code> C:\output>ffmpeg -r 15 -i rfrac%04d.png -f flv fractal.flv</code><br />
<br />
creates a Flash video file of with the same framerate as used on Youtube. You should be able to submit it to Youtube without the need for the Youtube servers to have to re-compress it.<br />
<br />
== Notes ==<br />
<br />
=== note 1 - wtf is yuv? ===<br />
<br />
The yuv file is rendered but it seems to have a not compatible format. See the console output when try to convert to a avi using ffmepg.<br />
<br />
<code><br />
ffmpeg -i RenderTest.yuv -sameq RenderTest.avi<br />
FFmpeg version SVN-rUNKNOWN, Copyright (c) 2000-2004 Fabrice Bellard<br />
configuration: --enable-gpl --enable-pp --enable-pthreads --enable-vorbis --enable-libogg --enable-a52 --enable-dts --enable-libgsm --enable-dc1394 --disable-debug --enable-shared --prefix=/usr <br />
libavutil version: 0d.49.0.0<br />
libavcodec version: 0d.51.11.0<br />
libavformat version: 0d.50.5.0<br />
built on Sep 20 2006 00:26:15, gcc: 4.1.2 20060906 (prerelease) (Ubuntu 4.1.1-13ubuntu2)<br />
picture size invalid (0x0)<br />
[rawvideo @ 0xb7f47c30]Could not find codec parameters (Video: rawvideo, yuv420p)<br />
RenderTest.yuv: could not find codec parameters<br />
</code><br />
<br />
I can watch a .yuv animation. You need to specify the size it was rendered at - that doesn't seem to be part of the file format:<br />
animate -size 480x270 file.yuv<br />
<br />
I can single-step through a .yuv animation, using SPACE to step forward and BACKSPACE to step back through the frames:<br />
display -size 480x270 file.yuv<br />
<br />
I can also convert a .yuv to a series of .png files. This makes file-0.png through file-23.png for a 24 frame animation:<br />
convert -size 480x270 file.yuv file.png<br />
<br />
I also discovered that ffmpeg will happily convert a .yuv to .avi if you just tell it the image dimensions:<br />
ffmpeg -s 480x270 -i file.yuv file.avi<br />
<br />
svn r980 adds headers to created .yuv files, so you no longer need to specify the size when using them. -- {{l|User:Dooglus|dooglus}} 21:50, 25 October 2007 (EDT)<br />
<br />
<br />
:Mmmm I can play yuv files with mplayer and with ffplay. Also I can convert a yuv file to an avi (or whatever ffmpeg can encode) without telling the video size. I think it depends on how ffmpeg was compiled. {{l|User:Genete|Genete}} 11:59, 4 June 2008 (EDT)<br />
<br />
<br />
=== note 2 - how to render for TV formats ===<br />
<br />
If you need to render stills (pngs) for something where the final format does not have square pixels, such as PAL or NTSC DV, you can use the approach outlined below.<br />
<br />
0) Select png format as you would otherwise<br />
<br />
1) Use square pixel when you edit it in synfig (1024x576 for PAL 16:9 and 768x576 for PAL 4:3. (Pixelgeek calculates this to be 958x540 for anamorphic and 720x540 for SD NTSC)<br />
<br />
2) Just before rendering, in canvas property->Other->Locks and links, set checkboxes for Image Aspect and Image Span, and uncheck Pixel Aspect (Depending on synfig version, this may possibly be the options dialog for File|Render, at least it is for me)<br />
<br />
3) Change back to the Image settings<br />
<br />
4) Change resolution to 720x576 for PAL, 720*480 for NTSC<br />
<br />
5) Render<br />
<br />
That should produce stills with the right "pixel aspect". When viewed on the PC using square pixels, a circle will appear as an oval. When viewed on a TV with the right pixelaspect, the circle will become a circle.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Keyframe&diff=19975Keyframe2015-01-02T11:44:09Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>{{NewTerminology}}<br />
{{Category|Glossary}}<br />
<br />
== What is a keyframe? ==<br />
<br />
A keyframe is a basically a "mark" in the timeline. This mark allows the user to make Synfig remember the state of the animation at that point (frame). It means that the keyframe is like a label that tell Synfig that this frame should be taken into account when creating waypoints. It also indicates that the marked frame is a special frame where the information of ''every parameter of every layer is stored in order to be reused later''. <br />
<br />
Each keyframe is associated with a particular frame and a frame can only have one keyframe.<br />
<br />
<br />
== What does a keyframe looks like? ==<br />
<br />
A keyframe looks like a light brown vertical dashed line in the {{l|Timetrack Panel}} placed at the corresponding frame. You can distinguish it from the {{l|Time_Cursor}} by its color (the time cursor is blue). <br />
<br />
{{l|File:KeyframesLook-TimeTrack 0.63.06.png|frame|none}}<br />
The symbols shown in the image are {{l|Waypoints|waypoints}}.<br />
<br />
The keyframe representation in the {{l|Timebar}} change according their states : {{literal|Normal}}, {{literal|Selected}} or {{literal|Deactivated}}<br />
{{l|File:Keyframe State Representation.png|frame|none}}<br />
<br />
Keyframes also appear as entries in a list in the {{l|Keyframes Panel}}<br />
{{l|File:KeyframesLook-KeyframePanel 0.63.06.png|frame|none}}<br />
<br />
'''Documentation writers note:''' You can download the project to generate the screenshot : {{l|File:Keyframe-lookslike.sifz}}<br />
<br />
== Keyframes and waypoints ==<br />
<br />
A keyframe doesn't necessarily imply a waypoint, and a waypoint doesn't necessarily imply a keyframe. <br />
<br />
A keyframe could live all the time without any waypoint but it stores the information of the values of the parameters on that specific frame. If there is a waypoint there then the waypoint information (only the parameter value) is stored too. If there is no waypoint in the keyframe then its "stored" value is the result of the surrounding waypoints, its parameter values and the interpolation values the waypoints have. This means that a keyframe remembers the values of the parameters at that frame but does not keep them static at that frame. To maintain a parameter's value static in a certain frame you must use a waypoint.<br />
<br />
The creation of a waypoint can cause the creation of new waypoints on the neighboring keyframes depending on the current value of the {{l|Lock Keyframes}} state. So, maybe, the creation of a waypoint (modifying a parameter or pasting or moving a waypoint or even duplicating a keyframe) can lead to the creation of a waypoint in the keyframes that are immediately before and after the inserted waypoint's frame. The waypoints created in the neighboring keyframes are created according to the {{l|New Layer Defaults#Default Interpolation|default interpolation value}} in the {{l|Toolbox |toolbox window}}.<br />
<br />
See the {{l|#Examples|examples}} to understand how this works.<br />
<br />
== Adding, duplicating and removing keyframes ==<br />
<br />
===Add a keyframe===<br />
{{l|File:KeyframeButton AddNew 0.63.06.png|frame|none}}<br />
<br />
Place the time cursor at a frame where there isn't currently any keyframe. Then press the {{Literal|Add new Keyframe}} button. If you place the time cursor at a frame where there is currently an existing keyframe or if animation Start Time egals animation End Time (animation Duration is 0m 0s 1f) then the {{Literal|Add new Keyframe}} button is disabled. Once you press the button then a new entry is added to the list of keyframes and a vertical dashed line is added in the time line. No waypoint is created.<br />
<br />
===Duplicate a keyframe===<br />
{{l|File:KeyframeButton Duplicate 0.63.06.png|frame|none}}<br />
<br />
Select a keyframe in the keyframe list of the {{l|Keyframes Panel}} and place the cursor at a frame where there isn't currently any keyframe. Then press the {{Literal|Duplicate Keyframe}} button. This would have two separated effects:<br />
<br />
# If there is a waypoint at the original keyframe then the waypoint is duplicated. Its duplication includes the parameter value and its interpolation types.<br />
# If there is no waypoint in the original keyframe for any particular parameter then two things could happen:<br />
#*There is no waypoint for that parameter at ANY frame in the time line: Then NO waypoint is created.<br />
#*If there is a waypoint in the time line for that parameter, but not in the keyframe that is going to be duplicated, then in the duplicated keyframe is created a new waypoint with a value for the parameter of the result of the current value at the original keyframe and a {{Literal|TCB Smooth}} interpolation type for both {{Literal|In}} and {{Literal|Out}}.<br />
<br />
Of course, duplicate a keyframe will produce a new keyframe at the place pointed by the time cursor and will add a new one to the keyframe list in the proper place. In the keyframe list, the new added keyframe have the same description than the original, plus a {{Literal|(Duplicate)}} at the end.<br />
<br />
===Remove a keyframe===<br />
{{l|File:KeyframeButton Remove 0.63.06.png|frame|none}}<br />
<br />
Just select a keyframe from the keyframe list and press the Remove keyframe button. It will remove the keyframe and all the waypoints for all parameters for all layers that are currently there.<br />
<br />
<cite>''NOTE: If you move a keyframe by modifying its {{l|#Time|time}} in the keyframe list dialog and immediately press the Remove Keyframe button then the waypoints are not deleted. It seems to be a bug but also can be considered a feature if you really want to keep the waypoints and not the keyframe.''</cite><br />
<br />
== Editing keyframes: time, length & description ==<br />
<br />
You can see in the Keyframe list dialog that there are four headers and before that, an empty column. This empty column maintain checkboxs related to keyframe activation : enabled or disabled. <br />
<br />
{{l|File:KeyframesLook-KeyframePanel 0.63.06.png|frame|none}}<br />
<br />
* "Empty" [CheckBox]<br />
* Time<br />
* Length<br />
* Jump<br />
* Description<br />
<br />
=== Activation ===<br />
By changing the state of the checkbox you can activate or disable the keyframe. A visual information about the keyframe state is displayed in the {{l|Timebar}}.<br />
<br />
=== Time ===<br />
<br />
You can modify the time (frame) where the keyframe is placed just making a click in the corresponding {{Literal|Time}} cell. It will allow modify the time forward or backward the amount that you want. You can also manually place a keyframe at the desired time using the {{l|Timebar}}.<br />
<br />
Modifying the Time of a keyframe has the following effects:<br />
<br />
# The existing {{l|Waypoints}} in the keyframe will move to the new position.<br />
# If any parameter have a a waypoint in the time line, then the moved keyframe will have a new waypoint set to {{l|New_Layer_Defaults#Default_Interpolation|default interpolation}} on those paramter(s).<br />
# According to the default interpolation method and the {{l|Lock Keyframes}} status and to the parameters that have any waypoint in the time line, new waypoints will be created on the neighbouring keyframes of the destiny time (frame). The original neighbouring keyframes will be untouched if don't coincide with the destiny neighbouring keyframes.<br />
# If a keyframe is displaced and doesn't "jump" over other existing keyframe then the waypoints that are surrounding the original position of the moved keyframe are compressed and / or expanded in the timeline depending on the displacement of the keyframe. See the examples. <cite> This is a recent discovered behaviour</cite><br />
<br />
You cannot set the time of other keyframe. If you try to set the time of a certain keyframe to be the same time of another existing keyframe then the program gives you this message:<br />
<br />
keyframe_set: Cannot change keyframe time because another keyframe already exists<br />
with that time.<br />
<br />
See {{l|#Change Keyframe Time|the example}} to see how changing the time of a keyframe works.<br />
<br />
=== Length ===<br />
<br />
Length parameter sets the time the keyframe is exposed in the timeline until next keyframe. You can also manually change the length parameter using the {{l|Timebar}} and holding {{Shortcut|alt}} key on releasing the mouse button.<br />
<br />
Changing the parameter shifts all following keyframes and {{l|Waypoints}} forward or backwards.<br />
<br />
=== Jump ===<br />
<br />
The Jump column is only a short cut to place the {{l|Time_Cursor}} at the keyframe where you make a click in the {{Literal|(JMP)}} label.<br />
<br />
=== Description ===<br />
<br />
This cell allow the user insert a short description of the meaning of the keyframe. Just make click on it and change the text.<br />
<br />
== Editing Keyframe Properties ==<br />
{{l|File:KeyframeButton Properties 0.63.06.png|frame|none}}<br />
<br />
Hitting the keyframe Properties button, the {{Literal|Keyframe Properties}} dialog will appear. This dialog allows change the interpolation method for all the waypoints on the keyframe at the same time. Even if, for a certain parameter, there is no waypoint on the keyframe but the parameter have other waypoints in the time line, then when you apply the {{Literal|Keyframe Properties}} you will add a waypoint at that keyframe were there aren't currently any waypoint. The added waypoints have the interpolation methods stated by the dialog. It means that the {{Literal|Keyframe Properties}} dialog will modify the interpolation methods for all the parameters that have any waypoint in the time line.<br />
<br />
The dialog have the following parameters:<br />
<br />
{{l|File:KeyframeDialog 0.63.06.png|frame|none}}<br />
* In: Checking this value you can change the interpolation method of the left part of the waypoints of the current selected keyframe of all the layers of the canvas to the selected {{l|Waypoints#Interpolation|interpolation method}} in the drop down menu.<br />
* Out: Same but for the right part of the waypoint.<br />
* Tension: See {{l|TCB}}<br />
* Bias: See {{l|TCB}}<br />
* Continuity: See {{l|TCB}}<br />
* Temporal Tension: See {{l|TCB}}<br />
<br />
You can check only one of both {{Literal|In}} or {{Literal|Out}} check boxes to only affect the change to the left or right part of the waypoints. The non checked part would not be modified. Same comment applies for the Manual interpolation method parameters ({{Literal|Tension}}, {{Literal|Bias}}, {{Literal|Continuity}} and {{Literal|Temporal Tension}})<br />
<br />
{{l|File:KeyframeDialog2 0.63.06.png|frame|none}}<br />
<br />
This dialog would not affect what's the interpolation method for a new waypoint created by the user, automatically created by the {{l|Keyframe#Duplicate_a_keyframe|keyframe duplication}} or by the {{l|Lock_Keyframes|lock keyframe}} state. The interpolation methods for new waypoints created in those cases will be both the same ({{Literal|In}} and {{Literal|Out}} or Left and Right) and depend only on the {{l|New_Layer_Defaults#Default_Interpolation|Default interpolation}} method of the {{l|:Category:Toolbox|Toolbox}} window.<br />
<br />
See the {{l|#Examples|examples}} to understand better how it works.<br />
<br />
==Examples ==<br />
<br />
=== Duplicate a keyframe with no waypoint on it ===<br />
For example, imagine that you have following set of keyframes and waypoints and the corresponding parameter of the radius of a circle:<br />
{|<br />
{| border = "1"<br />
|+ Before duplicate keyframe at 2s to 6s<br />
!Frame!!Keyframe!!Waypoint!!Radius!!Interpolation<br />
|-<br />
|0s||yes||yes||20.0||TCB Smooth<br />
|-<br />
|2s||yes||no||25.0||n/a<br />
|-<br />
|4s||yes||no||30.0||n/a<br />
|-<br />
|8s||no||yes||40.0||TCB Smooth<br />
|} <br />
<br />
<br />
{{l|File:Keyframe-GraphBeforeDuplicate 0.63.06.png|frame|none}}<br />
<br />
notice that although the interpolation between 0s and 8s is TCB Smooth the real result <br />
is linear due that they are the only two waypoints of the animation for that parameter.<br />
<br />
If you select the keyframe at 2s, place the time cursor at 6s (where there isn't a keyframe), set the {{l|New Layer Defaults#Default interpolation | default interpolation}} to {{l|TCB|TCB Smooth}}, and have the {{l|Lock Keyframes | lock keyframe status}} to {{Literal|All keyframes locked}} and press the {{Literal|Duplicate keyframe}} button, then the result is the following:<br />
<br />
{| border = "1"<br />
|+ After duplicate keyframe at 2s to 6s<br />
!Frame!!Keyframe!!Waypoint!!Radius!!Interpolation<br />
|-<br />
|0s||yes||yes||20.0||TCB Smooth<br />
|-<br />
|2s||yes||no||25,78125||n/a<br />
|-<br />
|4s||yes||yes||30.0||TCB Smooth<br />
|-<br />
|6s||yes||yes||25.0||TCB Smooth<br />
|-<br />
|8s||no||yes||40.0||TCB Smooth<br />
|}<br />
<br />
<br />
{{l|File:Keyframe-GraphAfterDuplicate 0.63.06.png|frame|none}}<br />
<br />
You can see that:<br />
# At 0s none has changed. Not affected by the insertion of the keyframe. It is two keyframes away from 6s and also have a waypoint.<br />
# At 2s there was a keyframe and stills there. But previous to the creation of the keyframe at 6s the current interpolated value of the {{Literal|radius}} was 25.0. After the creation of the keyframe at 6s the radius is the result of the interpolation between 0s and 4s frames waypoints with its radius values and its interpolation methods. That is 25.78125. This keyframe is more than one keyframe away from the new 6s keyframe so no waypoint is created.<br />
#At 4s there was a keyframe and still being there. But in this case the 4s keyframe is a neighbor of the new 6s keyframe. As well as the lock keyframe state was set to {{Literal|All keyframes locked}} then the keyframe at 4s has been locked adding a waypoint on it. The radius value hasn't changed (still being 30.0) because it was locked adding a waypoint with its current value). The Interpolation mode of the waypoint was set to {{Literal|TCB Smooth}} as stated by its default value.<br />
# At 6s there is a new keyframe with a new waypoint with the old value of the interpolated value of the keyframe at 2s. That is a {{Literal|radius}} of 25.0.<br />
#At 8s nothing has changed. There wasn't any keyframe and there was a waypoint so nothing is expected to change.<br />
<br />
Return to the previous state before you duplicate the keyframe with the {{l|History Panel}}, and imagine now that you do the same operations but you choose the default interpolation set to {{l|Constant}}. Then the result is the following:<br />
<br />
{| border = "1"<br />
|+ After duplicate keyframe at 2s to 6s (constant interpolation)<br />
!Frame!!Keyframe!!Waypoint!!Radius!!Interpolation<br />
|-<br />
|0s||yes||yes||20.0||TCB Smooth<br />
|-<br />
|2s||yes||no||20.0||n/a<br />
|-<br />
|4s||yes||yes||30.0||Constant<br />
|-<br />
|6s||yes||yes||25.0||TCB Smooth<br />
|-<br />
|8s||no||yes||40.0||TCB Smooth<br />
|}<br />
<br />
<br />
{{l|File:Keyframe-GraphAfterDuplicateConstant 0.63.06.png|frame|none}}<br />
<br />
<br />
Now you can see that the keyframe at 2s doesn't hold the value of the parameter by itself. It only remember the value if a waypoint is created on it, by the result of the insertion of a neighbour waypoint, or if a keyframe is duplicated and the lock keyframe status affects that keyframe. In this example the value at 2s has changed drastically due to the different interpolation method for the created waypoint on 4s. If in this situation you duplicate again the keyframe at 2s to other frame (ej. 10s) then it would copy a keyframe with a waypoint on it with a radius's value of 20.0, what is the current value of the parameter in that keyframe before duplicate it.<br />
<br />
'''Documentation writers note:''' You can download the project to generate the screenshot : {{l|File:Keyframe-example1.sifz}}<br />
<br />
=== Editing Keyframe Properties ===<br />
<br />
Consider this situation for a certain layer:<br />
<br />
{{l|File:KeyframeProperties-BeforeChange 0.63.06.png|frame|none}}<br />
<br />
In the sample the animation duration is 10 seconds so the image shows all the existing waypoints and keyframes. The time cursor isn't over any keyframe.<br />
<br />
Now consider that you have the following default values:<br />
<br />
* {{l|New Layer Defaults#Default Interpolation|Default Interpolation}} method set to {{Literal|Ease in/out}}<br />
* {{l|Lock Keyframes| Lock Keyframes}} status set to {{Literal|All Keyframes Locked}}<br />
<br />
Now select the keyframe at frame 4s in the keyframe list. Press the {{Literal|Keyframe Properties}} button and set the following interpolation method:<br />
<br />
{{l|File:KeyframeDialog3 0.63.06.png|frame|none}}<br />
<br />
and press {{Literal|Apply}} button. The result will be this:<br />
<br />
{{l|File:KeyframeProperties-After 0.63.06.png|frame|none}}<br />
<br />
You can see the following effects:<br />
<br />
# The existing waypoints at 4s keyframe have changed its interpolation methods according to the {{Literal|Keyframe Properties}} dialog.<br />
# There are new added waypoints at 4s keyframe. The waypoints are added to the paramters that have almost one waypoint in the time line (for example the one that have only a waypoint at 9s). The added waypoints at 4s keyframe have the interpolation settings that was stated by the {{Literal|Keyframe Properties}} dialog.<br />
# New waypoints have been created for the neighbouring keyframes to 4s (2s and 6s) for all the parameters that have any waypoint in the time line. The waypoints are created in the neighbouring keyframes according to the {{l|Lock Keyframes |Lock Keyframes}} status. Also the created waypoints interpolation method responds to the {{l|New Layer Defaults#Default Interpolation|default interpolation}} method you have set.<br />
<br />
If in the {{Literal|Keyframe Properties}} dialog you were checked off the {{Literal|Out}} or the {{Literal|In}} check boxes then it would have happened two things:<br />
<br />
# The existing waypoints at 4s would only change its interpolation method on the side the check box was checked on. The other side will be untouched.<br />
# The new added waypoints will have the interpolation method set to {{Literal|TCB Smooth}} method where the check box is off and the interpolation method set by the {{Literal|keyframe properties}} dialog where the check box is on.<br />
<br />
{{l|File:KeyframeProperties-After2 0.63.06.png|frame|none}}<br />
<br />
In this sample it was only checked on the {{Literal|In}} check box.<br />
<br />
'''Documentation writers note:''' You can download the project to generate the screenshot : {{l|File:Keyframe-example2.sifz}}<br />
<br />
=== Change Keyframe Time ===<br />
<br />
==== Without waypoints between keyframes ====<br />
<br />
Consider again this situation for a certain layer: <br />
<br />
{{l|File:KeyframeProperties-BeforeChange 0.63.06.png|frame|none}}<br />
<br />
Now consider that you have the following default values:<br />
<br />
* {{l|New Layer Defaults#Default Interpolation|Default Interpolation}} method set to {{Literal|Ease in/out}}<br />
* {{l|Lock Keyframes| Lock Keyframes}} status set to {{Literal|All Keyframes Locked}}<br />
<br />
Now select the keyframe at frame 4s in the keyframe list. Make a click in the {{Literal|Time}} cell and modify the time to be 3s. The result will be this:<br />
<br />
{{l|File:KeyframeTime-After 0.63.06.png|frame|none}}<br />
<br />
==== With waypoints between keyframes ====<br />
<br />
Consider now this situation for a certain layer:<br />
<br />
{{l|File:KeyframeWaypointTime-BeforeChange 0.63.06.png|frame|none}}<br />
<br />
Now consider that you have the following default values:<br />
<br />
<br />
* {{l|New Layer Defaults#Default Interpolation|Default Interpolation}} method set to {{Literal|Ease in/out}}<br />
* {{l|Lock Keyframes| Lock Keyframes}} status set to {{Literal|All Keyframes Locked}}<br />
<br />
Now select the keyframe at 4s in the keyframe list. Make a click in the {{Literal|Time}} cell and modify the time to be 2s. The result is this:<br />
<br />
{{l|File:KeyframeWaypointTime-After 0.63.06.png|frame|none}}<br />
<br />
You can see how the waypoints at right and left of the moved keyframe have been compressed and expanded in the time line. Also notice that any waypoint has been formed in the moved keyframe at the paramter at the bottom of the list but yes in the static keyframes.<br />
<br />
It seems to be a bug (?) - to be verified.<br />
<br />
Trying to understand this behaviour I see that also the keyframes keep the waypoints between two adjacent keyframes although you move them, keeping the distribution of the waypoints in the portion of time line between keyframes. This behaviour doesn't happen if the moved keyframe "jumps" over other keyframe when moved. <cite> Please add here as much information you can discover about keyframes behaviour. It seems that there are some bugs and any information is welcome</cite><br />
<br />
'''Documentation writers note:''' You can download the project to generate the screenshot : {{l|File:Keyframe-example3.sifz}}<br />
<br />
== Advanced uses of keyframes ==<br />
<br />
===Reusing keyframes===<br />
If you want to learn more about advanced uses of keyframes see this tutorial about reusing animations. Keyframes can be like stored "poses" that can be reused several time in the animation. Very useful for lip sync. <br />
<br />
{{l|Reuse Animations}}<br />
<br />
===Usage of Onionskin===<br />
<br />
To properly use the onion skin feature ({{Shortcut|alt|O}} or {{c|<Menu Caret>|<View>|Toggle Onion Skin|}}) you should consider the frame where the keyframes are set. Onion skin will show you the before and after keyframes images with a 50% opaque copy of the current view. Also the current view is 50% opaque.<br />
<br />
See {{l|Onion Skin|Onion Skin}} for more detail.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Animate_Editing_Mode&diff=19974Animate Editing Mode2015-01-02T11:43:46Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Animate Editing Mode}}<br />
{{Category|Glossary}}<br />
{{Category|Canvas Window}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
<br />
<br />
Each canvas is either in Animate Editing Mode or it isn't.<br />
<br />
When in Animate Editing Mode, each time you edit a parameter (whether directly in the {{l|Parameters Panel}} or indirectly by moving a {{l|Handle}}), a {{l|Waypoint}} is created to remember the change, and the position on the {{l|Timetrack Panel}} at which the change happened.<br />
<br />
Depending on the value of the {{l|Lock Keyframes}} setting, waypoints may also be created in the next and previous {{l|Keyframe}} as well.<br />
<br />
When not in Animate Editing Mode, changes to a parameter will be applied throughout the entire timeline of the animation. If there are already waypoints on the timetrack for the parameter in question, this causes an error and your edit will be disallowed. The error message says: "You must be in Animate-Editing-Mode to directly manipulate this value"<br />
<br />
{|border="0" align="none" style="border-collapse" cellpadding="3" cellspacing="0"<br />
<br />
|-style="background:#silver"<br />
|'''Name'''||'''Icon'''<br />
<br />
|-<br />
||Animate Editing Mode Off<br />
||{{l|Image:Animate mode off icon.png|32px}}<br />
<br />
|-style="background:#eeeeee"<br />
||Animate Editing Mode On <br />
||{{l|Image:Animate mode on icon.png|32px}}<br />
<br />
|} <br />
<br />
Animate Editing Mode can be toggled on and off by clicking the round button to the right of the timetrack at the bottom of the canvas window. It will only be visible if your canvas has a non-zero end time, and will only be active if you're not currently using a tool which disables the timetrack, such as the {{l|Spline Tool}} or the {{l|Draw Tool}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Features&diff=19973Features2015-01-02T11:43:30Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><br />
<br />
; '''Spatial resolution-independence'''<br />
: Most elements are vector-based, and all layers are parametrically generated, hence even when changing the target resolution of a project, the only pixelation will occur in imported raster images, not the built-in components.<br />
<br />
; '''Temporal resolution independence'''<br />
: Animation-keyframes are automatically interpolated by the computer, resulting in smooth motion<br />
<br />
; '''High Dynamic-Range Imaging (HDRI)'''<br />
: By using floating-point math in the image calculations, HDRI processing allows canvases to internally understand a far greater range of pixel luminance, resulting in better lighting effects, and improved color composition.<br />
<br />
; '''Pentablet-friendly tools'''<br />
: The draw tool already reads the pressure sensitivity channel off your favorite tablets, for natural line weighting, and more to come!<br />
<br />
; '''Artist-oriented design'''<br />
: While it may not be obvious in this early state, Synfig (and its proprietary predecessors) has been designed from the ground up with animation workflow in mind.<br />
<br />
; '''Built-in CVS support'''<br />
: <small>I haven't tried this yet, but I saw it in the file menu and it looked nifty, so- Hey, feature!</small><br />
<br />
; '''Path-based Gradients'''<br />
: Unlike purely SVG-based vector software, and most consumer-level animation programs, Synfig has full support for gradient paths - gradients that follow along a drawn shape. This allows artists to easily add soft shading to animation without the trouble of painting it onto every frame.<br />
<br />
; '''Layers'''<br />
: Synfig supports a multitude of {{l|layer}}s of various types; geometric, gradients, filters, distortions, transformations, fractal and a few others.<br />
<br />
If you would like to see more features in synfig, please contribute to the {{l|wish list}}.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Group_Layer&diff=19972Group Layer2015-01-02T11:43:15Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Group Layer}}<br />
{{Category|Layers}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
{{l|Image:Layer other group icon.png|64px}}<br />
<br />
== About Group Layers==<br />
<br />
The {{Literal|Group Layer}} is a special layer that can hold other layers. It is generated via the {{l|Group}} command accessed via the context menu in the {{l|Layers Panel}} or through the {{l|Layer Menu}} in the {{l|Canvas Menu Caret}}. As well as grouping a set of layers it can also translate them, scale them, and even modify the time for the layers it contains.<br />
<br />
{{Literal|Group Layers}} can also be created through the {{l|New Layer Menu}}, using {{c|<New Layer>|<Other>|Group Layer|}}.<br />
<br />
==Parameters of Group Layers==<br />
<br />
The parameters of the {{Literal|Group Layers}} are:<br />
<br />
{|border="0" align="none" style="border-collapse" cellpadding="3" cellspacing="0" <br />
|-style="background:#c8c8c8"<br />
|'''Name'''||'''Value'''||'''Type''' <br />
|-<br />
||{{l|Image:Type_real_icon.png|16px}} {{l|Z Depth Parameter|Z Depth}}<br />
||0.000000<br />
||real<br />
<br />
|-style="background:#eeeeee"<br />
||{{l|Image:Type_real_icon.png|16px}} {{l|Amount Parameter|Amount}}<br />
||1.000000<br />
||real<br />
<br />
|-<br />
||{{l|Image:type_integer_icon.png|16px}} {{l|Blend Method|Blend Method}}<br />
||Composite<br />
||integer<br />
<br />
|-style="background:#eeeeee"<br />
||{{l|Image:Type_vector_icon.png|16px}} {{l|Origin Parameter|Origin}}<br />
||0.000000u,0.000000u<br />
||vector<br />
<br />
|-style="background:#"<br />
||{{l|Image:Type canvas icon 0.63.06.png|16px}} {{l|Group Layer#Canvas Parameter|Canvas Parameter}}<br />
||<No Image Selected><br />
||canvas<br />
<br />
|-style="background:#eeeeee"<br />
||{{l|Image:Type_real_icon.png|16px}} {{l|Zoom Parameter|Zoom}}<br />
||0.000000<br />
||real<br />
<br />
|-<br />
||{{l|Image:Type_time_icon.png|16px}} {{l|Time Offset Parameter|Time Offset}}<br />
||Of<br />
||time<br />
<br />
|-style="background:#eeeeee"<br />
||{{l|Image:Type_bool_icon.png|16px}} {{l|Children Lock}}<br />
||<br />
{| style="width:18px; height:16px" border="1"<br />
|- <br />
|}<br />
||bool (Static)<br />
<br />
|-<br />
||{{l|Image:Type_vector_icon.png|16px}} {{l|Focus Point}}<br />
||0.000000u,0.000000u<br />
||vector<br />
<br />
|-<br />
||{{l|Image:Type_real_icon.png|16px}} {{l|Group Layer#Outline Grow|Outline Grow}}<br />
||0.000000<br />
||real<br />
<br />
|}<br />
<br />
=== Canvas Parameter ===<br />
{{l|Image:Type canvas icon 0.63.06.png|64px}}<br />
<br />
This is "Group" by default if the {{Literal|Group Layers}} was created by grouping other layers, or {{Literal|No Image Selected}} if it was created from the {{l|New Layer Menu}}. This parameter lets you select another canvas.<br />
<br />
The canvas parameter presents a drop-down menu of the exported canvases, plus an extra entry called "Other...". Selecting "Other..." presents the user with a text entry box asking for the name of the canvas to use. The name typed should have the following format (where <nowiki>[ ]</nowiki> indicates an optional part, ( ) is for grouping, and * means "0 or more times"):<br />
<br />
<nowiki> [[filename]#][:]</nowiki>''id''(:''id'')*<br />
<br />
In its simplest form, this is just an ''id'', ie. the exported name of one of the child canvases of the current canvas.<br />
<br />
Other possibilities are:<br />
* if a '#' is present, the part before the '#' is interpreted as the filename of an external .sif file to use.<br />
* if the '#' is the first character of the string (ie. the filename is blank) then the '#' is ignored, and the current canvas is used instead<br />
* if a ':' appears before the first ''id'', it means to start at the root canvas of the current canvas<br />
* each subsequent :id steps down into the specified child<br />
<br />
Examples:<br />
* '''/usr/share/doc/synfig/examples/business_card.sifz#:IndividualCard''' -- gives the absolute path to a .sifz file, and says to use the canvas that was exported from its root canvas as "IndividualCard"<br />
* '''../../examples/business_card.sifz#:IndividualCard''' -- the same, but with a relative path to the .sifz file<br />
* '''#:sy:head:eyes:left''' -- look in the current composition, and starting from the root, navigate down through the canvas tree. Find a child canvas of the root canvas called 'sy', look in 'sy' for a child canvas called 'head', and so on.<br />
* ''':sy:head:eyes:left''' -- exactly as above. an empty filename is the same as not using the '#' at all<br />
* '''eyes:left''' -- without a ':' before the first ''id'', this starts at the current canvas (presumably the Group in question is in the "head" subcanvas of the "sy" subcanvas of the root)<br />
<br />
=== Outline Grow Parameter ===<br />
This parameter allows to control thickness of all outline layers inside. Assigning positive value to this parameter makes all child outlines rendered thicker, while negative value makes them look thinner. This feature is very helpful for tuning outlines in complex artwork and it also allows to achieve some nice effects like constant outline width at any zoom level.<br />
<br />
Note: The {{Literal|Outline Grow}} parameter can not be applied to exported and imported (external) Groups layers.<br />
<br />
{{l|Image:Paste-canvas-outline-grow-param.png}}</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Layers&diff=19971Layers2015-01-02T11:41:39Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Layers}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
The following layer types are available in synfig:<br />
<br />
== Blurs ==<br />
<br />
=== {{l|Blur Layer|Blur}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Size<br />
| Size of Blur<br />
|-<br />
| Type<br />
| Type of blur to use<br />
|}<br />
<br />
Example: ( [http://www.youtube.com/watch?v=bmCpV2Q5lfI youtube] [http://www.musikboden.se/synfigfiles/blur.sif corresponding sif file] )<br />
<br />
=== {{l|Motion Blur Layer|Motion Blur}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Aperture<br />
| Shutter Time<br />
|}<br />
<br />
=== {{l|Radial Blur Layer|Radial Blur}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Origin<br />
| Point where you want the origin to be<br />
|-<br />
| Size<br />
| Size of blur<br />
|-<br />
| Fade Out<br />
|<br />
|}<br />
<br />
Example: ( [http://www.youtube.com/watch?v=X7V5e4A2xwk youtube] [http://www.musikboden.se/synfigfiles/radial_blur.sif corresponding sif file] )<br />
<br />
== Distortions ==<br />
<br />
=== {{l|Curve Warp Layer|Curve Warp}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Origin<br />
| Defines the where the center will be<br />
|-<br />
| Width<br />
| How much is expanded the result perpendicular to the source line <br />
|-<br />
| Start Point<br />
| First point of the source line<br />
|-<br />
| End Point<br />
| Final point of the source line<br />
|-<br />
| Vertices<br />
| List of Spline Points where the source line is curved to<br />
|-<br />
| Fast<br />
| When checked, renders quickly but with artifacts <br />
|}<br />
<br />
=== {{l|Inside Out Layer|Inside Out}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Origin<br />
| Defines the where the center will be<br />
|}<br />
<br />
=== {{l|Noise Distort Layer|Noise Distort}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Displacement<br />
| How much the distortion is displaced form its original position.<br />
|-<br />
| Size<br />
| How much separated are two consecutive distortions . <br />
|-<br />
| Random Seed<br />
| Defines the random generator number seed.<br />
|-<br />
| Interpolation<br />
| What type of interpolation to use<br />
|-<br />
| Detail<br />
| Lower/higher values produces less/more detailed distortions.<br />
|-<br />
| Animation Speed<br />
| In times per second, defines the frequency of change of the distortion.<br />
|-<br />
| Turbulent<br />
| When checked it produces turbulent distortions.<br />
|}<br />
<br />
Example: ( [http://www.youtube.com/watch?v=rc39nnd7R_4 youtube] [http://www.musikboden.se/synfigfiles/noise_distort_area.sif corresponding sif file] )<br />
<br />
=== {{l|Spherize Layer|Spherize}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Position<br />
| The center (or axis) of the distortion.<br />
|-<br />
| Radius<br />
| Defines the radious of the distortion (spherize) or a half of the bar (vertical or horizontal bar)<br />
|-<br />
| Amount<br />
| Defines how much convex (positive) or concave (negative) the distortion is<br />
|-<br />
| Clip<br />
| When checked it only distorts inside the Radious area.<br />
|-<br />
| Distort Type<br />
| The direction of the distortion (spherize, horizontal bar, vertical bar).<br />
|}<br />
<br />
Example: ( [http://www.youtube.com/watch?v=AZ3vjLqUTW0 youtube] [http://www.musikboden.se/synfigfiles/spherize_area.sif corresponding sif file] )<br />
<br />
=== {{l|Stretch Layer|Stretch}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Amount<br />
| Its distance to Center defines how much the image is stretched or is shrunk <br />
|-<br />
| Center<br />
| The position from where the distortion is made.<br />
|}<br />
<br />
Example: ( [http://www.youtube.com/watch?v=JCkZgOloKZc youtube] [http://www.musikboden.se/synfigfiles/stretch_area.sif corresponding sif file] )<br />
<br />
=== {{l|Twirl Layer|Twirl}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Center<br />
| The position of the twirl distortion.<br />
|-<br />
| Radius<br />
| This is the radius of the circle of the twirl distortion<br />
|-<br />
| Rotations<br />
| Defines how many rotations (in DEG) the twirl produces.<br />
|-<br />
| Distort Inside<br />
| Defines if the distortion is produced inside the radious area.<br />
|-<br />
| Distort Outside<br />
| Defines if the distortion is produced outside the radious area. <br />
|}<br />
<br />
Example: ( [http://www.youtube.com/watch?v=eqqVuMa0WdQ youtube] [http://www.musikboden.se/synfigfiles/twirl_area.sif corresponding sif file] )<br />
<br />
=== {{l|Warp Layer|Warp}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Source TL<br />
| Top Left point of the source to warp.<br />
|-<br />
| Source BR<br />
| Bottom Right point of the source to warp.<br />
|-<br />
| Dest TL<br />
| Top Left point of the destination where to warp.<br />
|-<br />
| Dest TR<br />
| Top Right point of the destination where to warp.<br />
|-<br />
| Dest BR<br />
| Bottom Right point of the destination where to warp.<br />
|-<br />
| Dest BL<br />
| Bottom Left point of the destination where to warp.<br />
|-<br />
| Clip<br />
| When checked it only renders what is inside the source rectangle.<br />
|-<br />
| Horizon<br />
| A number to define when to stop rendering when do a perspective warp. High values produces far horizons.<br />
|}<br />
<br />
Example: ( [http://www.youtube.com/watch?v=V3MY8VGtVGc youtube] [http://www.musikboden.se/synfigfiles/warp_area.sif corresponding sif file] )<br />
<br />
== Filters ==<br />
<br />
=== {{l|Clamp Layer|Clamp}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Invert Negative<br />
|<br />
|-<br />
| Clamp Ceiling<br />
|<br />
|-<br />
| Ceiling<br />
|<br />
|-<br />
| Floor<br />
|<br />
|}<br />
<br />
=== {{l|Color Correct Layer|Color Correct}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Hue Adjust<br />
|<br />
|-<br />
| Brightness<br />
|<br />
|-<br />
| Contrast<br />
|<br />
|-<br />
| Exposure Adjust<br />
|<br />
|-<br />
| Gamma Adjustment<br />
|<br />
|}<br />
<br />
=== {{l|Halftone 2 Layer|Halftone 2}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Mask Offset<br />
|<br />
|-<br />
| Mask Angle<br />
|<br />
|-<br />
| Mask Size<br />
|<br />
|-<br />
| Light Color<br />
|<br />
|-<br />
| Dark Color<br />
|<br />
|-<br />
| Type<br />
|<br />
|}<br />
<br />
=== {{l|Halftone 3 Layer|Halftone 3}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Mask Size<br />
|<br />
|-<br />
| Type<br />
|<br />
|-<br />
| Subtractive Flag<br />
|<br />
|-<br />
| <Channel Name>Color<br />
|<br />
|-<br />
| <Channel Name>Mask Offset<br />
|<br />
|-<br />
| <Channel Name>Mask Angle<br />
|<br />
|}<br />
<br />
=== {{l|Luma Key Layer|Luma Key}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Color of checkers<br />
|-<br />
| Offset<br />
|<br />
|-<br />
| Size<br />
| Size of checkers<br />
|}<br />
<br />
== Fractals ==<br />
<br />
=== {{l|Julia Set Layer|Julia Set}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Inside Color<br />
| Color of the Set<br />
|-<br />
| Outside Color<br />
| Color outside the Set<br />
|-<br />
| Color Shift<br />
|<br />
|-<br />
| Iterations<br />
|<br />
|-<br />
| Seed Point<br />
|<br />
|-<br />
| Bailout ValueBase<br />
|<br />
|-<br />
| Distort Inside<br />
|<br />
|-<br />
| Shade Inside<br />
|<br />
|-<br />
| Solid Inside<br />
|<br />
|-<br />
| Invert Inside<br />
|<br />
|-<br />
| Color Inside<br />
|<br />
|-<br />
| Distort Outside<br />
|<br />
|-<br />
| Shade Outside<br />
|<br />
|-<br />
| Solid Outside<br />
|<br />
|-<br />
| Invert Outside<br />
|<br />
|-<br />
| Color Outside<br />
|<br />
|-<br />
| Color Cycle<br />
|<br />
|-<br />
| Smooth Outside<br />
| Smooth the coloration outside the set<br />
|-<br />
| Break Set<br />
| Modify equation to achieve interesting results<br />
|}<br />
<br />
=== {{l|Mandelbrot Set Layer|Mandelbrot Set}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Iterations<br />
|<br />
|-<br />
| Bailout ValueBase<br />
|<br />
|-<br />
| Break Set<br />
| Modify equation to achieve interesting results<br />
|-<br />
| Distort Inside<br />
|<br />
|-<br />
| Shade Inside<br />
|<br />
|-<br />
| Solid Inside<br />
|<br />
|-<br />
| Invert Inside<br />
|<br />
|-<br />
| Gradient Inside<br />
|<br />
|-<br />
| Offset Inside<br />
|<br />
|-<br />
| Loop Inside<br />
|<br />
|-<br />
| Distort Outside<br />
|<br />
|-<br />
| Shade Outside<br />
|<br />
|-<br />
| Solid Outside<br />
|<br />
|-<br />
| Invert Outside<br />
|<br />
|-<br />
| Gradient outside<br />
|<br />
|-<br />
| Smooth Outside<br />
| Smooth the coloration outside the set<br />
|-<br />
| Offset Outside<br />
|<br />
|-<br />
| Scale Outside<br />
|<br />
|}<br />
<br />
== Geometry ==<br />
<br />
=== Common Parameters ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Z Depth<br />
| Relative displacement of the depth of the layer inside the canvas<br />
|-<br />
| Amount<br />
| Overall alpha amount of the layer. <br />
|-<br />
| Blend Method<br />
| Type of blend method.<br />
|}<br />
<br />
<br />
=== {{l|Checkerboard Layer|Checkerboard}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Color of checkers.<br />
|-<br />
| Offset<br />
| Displacement of the checkboard origin.<br />
|-<br />
| Size<br />
| Size of checkers.<br />
|}<br />
<br />
=== {{l|Circle Layer|Circle}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Circle's color.<br />
|-<br />
| Radius<br />
| Circle's radious.<br />
|-<br />
| Feather<br />
| Circle feather amount.<br />
|-<br />
| Center<br />
| Circle's center.<br />
|-<br />
| Invert<br />
| Invert the circle<br />
|-<br />
| Falloff<br />
| Determines the falloff function for the feather<br />
|}<br />
<br />
=== {{l|Outline Layer|Outline}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Outline's color.<br />
|-<br />
| Offset<br />
| Displacement of the Outline from the (0,0).<br />
|-<br />
| Invert<br />
| When checked it inverts alpha results of the layer. <br />
|-<br />
| Antialiasing<br />
| When checked it produces antialiased renders for the layer.<br />
|-<br />
| Feather <br />
| Outline feather amount.<br />
|-<br />
| Type of Feather<br />
| Defines the type of feather.<br />
|-<br />
| Winding Style.<br />
| Defines overlapping behavior. <br />
|-<br />
| Vertices<br />
| A list of Spline Points<br />
|-<br />
| Outline Width<br />
| Default widths of the points.<br />
|-<br />
| Expand<br />
| Defines a value to add to the Outline width. <br />
|-<br />
| Sharp Cusps<br />
| When chekced it produces sharp corners.<br />
|-<br />
| Rounded Begin<br />
| Round off the begin tip<br />
|-<br />
| Rounded End<br />
| Round off the end tip<br />
|-<br />
| Loopyness<br />
|<br />
|-<br />
| Homogeneous<br />
|<br />
|}<br />
<br />
<br />
=== {{l|Advanced_Outline_Layer|Advanced Outline}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Outline's color.<br />
|-<br />
| Offset<br />
| Displacement of the Outline from the (0,0).<br />
|-<br />
| Invert<br />
| When checked it inverts alpha results of the layer. <br />
|-<br />
| Antialiasing<br />
| When checked it produces antialiased renders for the layer.<br />
|-<br />
| Feather <br />
| Outline feather amount.<br />
|-<br />
| Type of Feather<br />
| Defines the type of feather.<br />
|-<br />
| Winding Style.<br />
| Defines overlapping behavior. <br />
|-<br />
| Vertices<br />
| A list of Spline Points<br />
|-<br />
| Outline Width<br />
| Default widths of the points.<br />
|-<br />
| Expand<br />
| Defines a value to add to the Outline width. <br />
|-<br />
| Tip Type at Start<br />
| Define the Tip Type of the first spline point when the spline is unlooped<br />
|-<br />
| Tip Type at End<br />
| Define the Tip Type of the last spline point when the spline is unlooped<br />
|-<br />
| Cusps Type<br />
| Determine Cusps Type<br />
|-<br />
| Smoothness<br />
| Determine the interpolation between withpoints. (0) Linear, (1) Smooth<br />
|-<br />
| Homogeneous<br />
| When true, witdhpoints position are spline length based.<br />
|-<br />
| Width Point List<br />
| List of with point that defines the variable width<br />
|-<br />
| Fast<br />
| When checked, outline render fast but less accurate<br />
|-<br />
| Dashed Outline<br />
| When checked, outline is dashed<br />
|-<br />
| Dashed Item List<br />
| List of dash items that defines the dashed outline<br />
|-<br />
| Dashed Item Offset<br />
| Distance to Offset the Dash Items<br />
|}<br />
<br />
=== {{l|Polygon Layer|Polygon}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Vector List<br />
| A list of Vector points.<br />
|}<br />
<br />
=== {{l|Rectangle Layer|Rectangle}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Rectangle's color.<br />
|-<br />
| Point 1<br />
| Position of the first point of the diagonal<br />
|-<br />
| Point 2<br />
| Position of the second point of the diagonal.<br />
|-<br />
| Expand amount<br />
| Amount of expansion around the rectangle's edge.<br />
|-<br />
| Invert the rectangle<br />
| If checked on inverts the alpha value of the layer.<br />
|}<br />
<br />
=== {{l|Region Layer|Region}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Region's color.<br />
|-<br />
| Offset<br />
| Displacement of the Region from the (0,0).<br />
|-<br />
| Invert<br />
| When checked it inverts alpha results of the layer. <br />
|-<br />
| Antialiasing<br />
| When checked it produces antialiased renders for the layer.<br />
|-<br />
| Feather <br />
| Outline feather amount.<br />
|-<br />
| Type of Feather<br />
| Defines the type of feather.<br />
|-<br />
| Winding Style.<br />
| Defines overlapping behavior. <br />
|-<br />
| Vertices<br />
| A list of Spline Points<br />
|}<br />
<br />
=== {{l|Solid Color Layer|Solid Color}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
|<br />
|}<br />
<br />
=== {{l|Star Layer|Star}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Outer Radius<br />
| The radius of the outer points in the star<br />
|-<br />
| Inner Radius<br />
| The radius of the inner points in the star<br />
|-<br />
| Angle<br />
| The orientation of the star<br />
|-<br />
| Points<br />
| The number of points in the star<br />
|}<br />
<br />
== Gradients ==<br />
<br />
=== {{l|Conical Gradient Layer|Conical Gradient}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Gradient<br />
| The gradient that's going to be mapped to the cone.<br />
|-<br />
| Center<br />
| The center of the cone.<br />
|-<br />
| Angle<br />
| The angle where the beginning and the end of the gradient join.<br />
|-<br />
| Symmetric<br />
| Cheked on produces a symmetrical gradient.<br />
|}<br />
<br />
=== {{l|Curve Gradient Layer|Curve Gradient}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Offset<br />
| Relative displacement of the gradient respect to the Spline.<br />
|-<br />
| Width<br />
| Default width of the gradient. <br />
|-<br />
| Vertices<br />
| A list of Spline Points<br />
|-<br />
| Gradient<br />
| The gradient parameter<br />
|-<br />
| Loop<br />
| If chekced on produces a looped gradient.<br />
|-<br />
| ZigZag<br />
| When checked on it produces a double gradient.<br />
|-<br />
| Perpendicular<br />
| If chekced on it produces a perpendicular gradient to Spline instead of parallel.<br />
|-<br />
| Fast<br />
| When cheked on it produces a faster render but less accurate gradient.<br />
|}<br />
<br />
=== {{l|Linear Gradient Layer|Linear Gradient}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Point 1<br />
| First point of he gradient.<br />
|-<br />
| Point 2<br />
| Second point of the gradient.<br />
|-<br />
| Gradient<br />
| The gradient parameter<br />
|-<br />
| Loop<br />
| If chekced on produces a looped gradient. <br />
|-<br />
| ZigZag<br />
| When checked on it produces a double gradient. <br />
|}<br />
<br />
=== {{l|Noise Gradient Layer|Noise Gradient}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Gradient<br />
| The gradient parameter.<br />
|-<br />
| Random Seed<br />
| Defines the random generator number seed.<br />
|-<br />
| Size<br />
| How much separated are two consecutive distortions <br />
|-<br />
| Interpolation<br />
| What type of interpolation to use<br />
|-<br />
| Detail<br />
| Lower/higher values produces less/more detailed distortions.<br />
|-<br />
| Animation Speed<br />
| In times per second, defines the frequency of change of the distortion. <br />
|-<br />
| Turbulent<br />
| When checked on it produces turbulent distortions. <br />
|-<br />
| Do Alpha<br />
|<br />
|-<br />
| Super Sampling<br />
| When chekced on produces more accurate results but slower renders. <br />
|}<br />
<br />
=== {{l|Radial Gradient Layer|Radial Gradient}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Gradient<br />
| The gradient parameter<br />
|-<br />
| Center<br />
| The center of the radial gradient.<br />
|-<br />
| Radius<br />
| This is the radius of the circle.<br />
|-<br />
| Loop<br />
| When cheked on it produces a looped gradient.<br />
|-<br />
| Zig-Zag<br />
| When checked on it produces a double gradient. <br />
|}<br />
<br />
=== {{l|Spiral Gradient Layer|Spiral Gradient}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Gradient<br />
| The gradient parameter<br />
|-<br />
| Center<br />
| The center of the spiral gradient.<br />
|-<br />
| Radius<br />
| This is the radius of the circle<br />
|-<br />
| Angle<br />
| The amount of rotations of the spiral. <br />
|-<br />
| Clockwise<br />
| When cheked on/off produces clockwise/counter-clockwise spiral gradient.<br />
|}<br />
<br />
== Other ==<br />
<br />
=== {{l|Duplicate Layer|Duplicate}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Index<br />
| Copy Index<br />
|}<br />
<br />
=== {{l|Import Image Layer|Import Image}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Filename<br />
| File to import<br />
|-<br />
| Time Offset<br />
| Time offset used for image sequence import.<br />
|}<br />
<br />
=== {{l|Group Layer|Group layer}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Origin<br />
| Point where you want the origin to be.<br />
|-<br />
| Canvas<br />
| Canvas to paste<br />
|-<br />
| Zoom<br />
| Amplification of the canvas (around the origin?)<br />
|-<br />
| Time Offset<br />
| Time to rewind (negative) or fast forward (positive) the animation of the canvas<br />
|-<br />
| Children Lock<br />
| When checked on you cannot select a child layer by clicking on it. <br />
|}<br />
<br />
=== {{l|Plant Layer|Plant}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Vertices<br />
| A list of Spline Points<br />
|-<br />
| Gradient<br />
| Gradient to be used for coloring the plant<br />
|-<br />
| Split Angle<br />
| Angle by which each split deviates from its parent<br />
|-<br />
| Gravity<br />
| Direction in which the shoots tend to face<br />
|-<br />
| Tangential Velocity<br />
| Amount to which shoots tend to grow along the tangent to the Spline<br />
|-<br />
| Perpendicular Velocity<br />
| Amount to which shoots tend to grow perpendicular to the tangent to the Spline<br />
|-<br />
| Stem Size<br />
| Size of the stem<br />
|-<br />
| SizeAsAlpha<br />
| If enabled, the alpha channel from the gradient is multiplied by the stem size, and an alpha of 1.0 is used when rendering<br />
|-<br />
| Step<br />
| Measure of the distance between points when rendering<br />
|-<br />
| Seed<br />
| Used to seed the pseudo-random number generator<br />
|-<br />
| Splits<br />
| Maximum number of times that each sprout can sprout recursively<br />
|-<br />
| Sprouts<br />
| Number of places that growth occurs on each Spline section<br />
|-<br />
| Random Factor<br />
| Used to scale down all random effects. Set to zero to disable randomness<br />
|-<br />
| Drag<br />
| Drag slows the growth<br />
|}<br />
<br />
=== {{l|Skeleton Layer|Skeleton}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Bones<br />
| Static list of bones elements<br />
|}<br />
<br />
=== {{l|Stroboscope Layer|Stroboscope}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Frequency<br />
| Frequency of the Stroboscope in times per second<br />
|}<br />
<br />
<br />
=== {{l|Super Sample Layer|Super Sample}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Width<br />
| Width of sample area (In pixels)<br />
|-<br />
| Height<br />
| Height of sample area (In pixels)<br />
|-<br />
| Use Parametric<br />
| Use the Parametric Renderer<br />
|-<br />
| Be Alpha Safe<br />
|<br />
|}<br />
<br />
=== {{l|Text Layer|Text}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Text<br />
| Text to Render<br />
|-<br />
| Color<br />
| Color of the text<br />
|-<br />
| Font Family<br />
| You could use values "Sans", "Times" or "Courier" for system fonts here. If you have ttf font file in the same dir as your sif/sifz file, then you may specify it's name (without extension). If ttf font file is located in another directory, then you may specify absolute or relative path to it.<br />
|-<br />
| Style<br />
|<br />
|-<br />
| Weight<br />
|<br />
|-<br />
| Horizontal Spacing<br />
| Describes how close glyphs are horizontally<br />
|-<br />
| Vertical Spacing<br />
| Describes how close lines of text are vertically<br />
|-<br />
| Size<br />
| Size of the text<br />
|-<br />
| Orientation<br />
| Text Orientation. Set to 0.0 for left aligned, 0.5 for centered and/or 1.0 for right aligned. <br />
|-<br />
| Position<br />
| Text Position<br />
|-<br />
| Kerning<br />
| Enables/Disables font kerning (If the font supports it)<br />
|-<br />
| Sharpen Edges<br />
| Turn this off if you are going to be animating the text<br />
|-<br />
| Invert<br />
|<br />
|}<br />
Fonts that appear to work under Linux - Courier, Times, Serif, Verdana, Sans Serif.<br><br />
Fonts that appear to work under Windows - Arial, Times New Roman/Serif, Verdana/Sans Serif. Courier produces an interesting, but non-legible effect.<br><br />
Sans Serif appears to be the default if Synfig doesn't recognize the font.<br />
<br />
=== {{l|TimeLoop Layer|Time Loop}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Link Time<br />
| Time where the loop starts.<br />
|-<br />
| Local Time<br />
| Used to line up the Offset time of the time loop.<br />
|-<br />
| Duration<br />
| Amount of time of the time loop.<br />
|-<br />
| Only For Positive Duration<br />
| Disable the Time Loop layer if Duration is <= 0.<br />
|-<br />
| Symmetrical<br />
| Provides compatibility for the previous Time Loop layer version.<br />
|}<br />
<br />
Example : [http://www.youtube.com/watch?v=7ITHpCSc5Ok tutorial (youtube)]<br />
<br />
=== {{l|XOR Pattern Layer|XOR Pattern}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Offset<br />
|<br />
|-<br />
| Size<br />
|<br />
|}<br />
<br />
== Stylize ==<br />
<br />
=== {{l|Bevel Layer|Bevel}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Type<br />
| Type of blur to use<br />
|-<br />
| Hi-Color<br />
| High color (where the light comes from)<br />
|-<br />
| Lo-Color<br />
| Low color (where the light goes to)<br />
|-<br />
| Light Angle<br />
| Angle of the light of the Bevel.<br />
|-<br />
| Depth of Bevel<br />
| Bigger values produce bigger Bevel detph.<br />
|-<br />
| Softness<br />
| Blur amount of the Bevel.<br />
|-<br />
| Use Luma<br />
|<br />
|-<br />
| Solid<br />
|<br />
|}<br />
<br />
=== {{l|Shade Layer|Shade}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Color of the shade<br />
|-<br />
| Offset<br />
| Relative displacement of the shade respecto the shaded layer(s)<br />
|-<br />
| Size<br />
| Size of blur of the shade<br />
|-<br />
| Type<br />
| Type of blur to use<br />
|-<br />
| Invert<br />
| When checked on inverts the alpha result of the shade.<br />
|}<br />
<br />
== Transform ==<br />
<br />
=== {{l|Rotate Layer|Rotate}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Origin<br />
| Point where you want the origin to be<br />
|-<br />
| Amount<br />
| Amount of rotation in degrees.<br />
|}<br />
<br />
=== {{l|Translate Layer|Translate}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Origin<br />
| Point where you want the origin to be<br />
|}<br />
<br />
=== {{l|Scale Layer|Scale}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Amount<br />
| Amount to scale in<br />
|-<br />
| Center<br />
| Point to scale in to<br />
|}<br />
<br />
== Not Available ==<br />
<br />
These layers are examples to aid developers in creating more layer types, but aren't included in binary releases of Synfig.<br />
<br />
=== {{l|Shape Layer|Shape}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
| Layer_Shape Color<br />
|-<br />
| Offset<br />
|<br />
|-<br />
| Invert<br />
|<br />
|-<br />
| Antialiasing<br />
|<br />
|-<br />
| Feather<br />
|<br />
|-<br />
| Type of Feather<br />
| Type of feathering to use<br />
|-<br />
| Winding Style<br />
| Winding style to use<br />
|}<br />
<br />
=== {{l|Metaballs Layer|Metaballs}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
|<br />
|-<br />
| Points<br />
|<br />
|-<br />
| Radii<br />
|<br />
|-<br />
| Weights<br />
|<br />
|-<br />
| Threshold<br />
|<br />
|}<br />
<br />
=== {{l|Simple Circle Layer|Simple Circle}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
|<br />
|-<br />
| Center<br />
|<br />
|-<br />
| Radius<br />
| This is the radius of the circle<br />
|}<br />
<br />
=== {{l|Filled Rectangle Layer|Filled Rectangle}} ===<br />
<br />
Parameters:<br />
{| border="1"<br />
|-<br />
! Parameter<br />
! Description<br />
|-<br />
| Color<br />
|<br />
|-<br />
| Point 1<br />
|<br />
|-<br />
| Point 2<br />
|<br />
|-<br />
| Feather X<br />
|<br />
|-<br />
| Feather Y<br />
|<br />
|-<br />
| Bevel<br />
|<br />
|-<br />
| Keep Bevel Circular<br />
|<br />
|}</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Challenges&diff=19970Challenges2015-01-02T11:40:22Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div>== What are you talking about? ==<br />
Every month the Synfig community organizes a fun [http://synfig.org/forums/viewforum.php?f=17 challenge] where people can show their talent, skills and humor using their favorite design tool: Synfig.<br />
<br />
All this great action takes place in the [http://synfig.org/forums/ Synfig Forums]. You can also participate and show all of us how good you are. There are some {{l|Challenges/Rules|rules}} for participation that you should follow.<br />
<br />
== Current challenge ==<br />
This month, {{l|User:pxegeek|pixelgeek}} has challenged us:<br />
<br />
... What happened here/what happens next? ...<br />
<br />
Read the [http://synfig.org/forums/viewtopic.php?f=17&t=1429 complete forum thread]...<br />
<br />
<br />
== Previous Challenges ==<br />
{{l|File:Synfig_examples_repository.png|200px|thumb|right|[http://www.synfig.org/en/examples-repository examples repository] on the Synfig website}} After the end of each challenge, a lot of useful and interesting resources are available. You can find all the stuff produced in previous challenge sessions. Click on the links to visit the past challenge, or browse the [http://www.synfig.org/en/examples-repository examples repository] where most of the recent challenges entries can be found:<br />
<br />
<br />
<br />
<br />
<br />
=== 2010 ===<br />
* September 2010 Challenge: What happened here? [http://synfig.org/forums/viewtopic.php?f=17&t=1429]<br />
* August 2010 Challenge: Tracing a photo [http://synfig.org/forums/viewtopic.php?p=7187#p7187]<br />
* July 2010 Challenge: A Kaleidoscope [http://synfig.org/forums/viewtopic.php?p=6827#p6827]<br />
* June 2010 Challenge: four leg walk cycle... [http://synfig.org/forums/viewtopic.php?p=6621#p6621]<br />
* May 2010 Challenge: Fire! [http://synfig.org/forums/viewtopic.php?p=5902#p5902]<br />
* March 2010 Challenge: New Splash challenge for Synfig 0.62.01 !! [http://synfig.org/forums/viewtopic.php?f=17&t=1071]<br />
* February 2010 Challenge: A flapping flag [http://synfig.org/forums/viewtopic.php?p=5077#p5077] <br />
<br />
=== 2009 ===<br />
* October 2009 Challenge: A dancing skeleton [http://synfig.org/forums/viewtopic.php?p=4184#p4184]<br />
* September 2009 Challenge: Splash Screen! [http://synfig.org/forums/viewtopic.php?p=3897#p3897]<br />
* August 2009 Challenge: Dram an insect [http://synfig.org/forums/viewtopic.php?p=3634#p3634]<br />
* July 2009 Challenge: Motion Blur [http://synfig.org/forums/viewtopic.php?p=3458#p3458]<br />
* June 2009 Challenge: Space - the final frontier [http://synfig.org/forums/viewtopic.php?p=3261#p3261]<br />
* {{l|Challenges/May2009|May 2009 Challenge: Something Random}}<br />
* {{l|Challenges/April2009|April 2009 Challenge: An Animated Flower/Plant}}<br />
* {{l|Challenges/March2009|March 2009 Challenge: A Bouncing Ball}}<br />
* {{l|Challenges/February2009|February 2009 Challenge: Stickman's Day Out}}<br />
* {{l|Challenges/January2009|January 2009 Challenge: Use Every Layer of Synfig}}<br />
<br />
=== 2008 ===<br />
* {{l|Challenges/December2008|December 2008: Season's Greetings}}<br />
* {{l|Challenges/November2008|November 2008: A looping background}}<br />
* {{l|Challenges/October2008|October 2008: Halloween!}}<br />
* {{l|Challenges/September2008|September 2008: Time for another splash screen}}<br />
* {{l|Challenges/August2008|August 2008: Kinetic typography}}<br />
* {{l|Challenges/July2008|July 2008: What goes around...}} <br />
* {{l|Challenges/June2008|June 2008: A Walk Cycle}} <br />
* {{l|Challenges/May2008|May 2008: Created with Synfig!}} <br />
* {{l|Challenges/April2008|April 2008: Nursery Rhyme}} <br />
* {{l|Challenges/March2008|March 2008: Monster Month}} <br />
* {{l|Challenges/February2008|February 2008: New Synfig splash screen}} ''already moved to website''<br />
* {{l|Challenges/January2008|January 2008: "Hello, Delilah!"}} ''already moved to website''</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Following_a_BLine_(the_very_old_way)&diff=19969Following a BLine (the very old way)2015-01-02T11:38:29Z<p>Ciaran: delete test</p>
<hr />
<div><!-- Page info --><br />
{{Title|Following a BLine (the very old way)}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
<!-- Page info end --><br />
<br />
:'''Out-of-date:''' This tutorial has been replaced by {{l|Doc:Following a Spline}}. This out-of-date tutorial is only of interest to people using very old versions of synfig (versions 0.63.05 and earlier). To get the latest version of synfig, see the [http://www.synfig.org/cms/en/download/stable downloads page].<br />
:BLine has been renamed Spline and other [http://www.synfig.org/cms/en/news/terminology-rewrite-sprint/ terminology has changed].<br />
<br />
== Introduction ==<br />
<br />
This is only a rough draft. The content should be OK, but it needs tidying up and could really benefit from some screen shots. If you follow the tutorial, please consider taking some shots as you do so and uploading them here...<br />
<br />
[http://sourceforge.net/tracker/index.php?func=detail&aid=1781903&group_id=144022&atid=757419 This bug report] suggested a feature:<br />
<br />
<blockquote><br />
I would like to be able to draw a bline with N vertices and have<br />
a shape move along that bline (the whole shape or individual vertices).<br />
Currently the only way I have found to do what I want is to draw a bline,<br />
and then move a shape along that line manually at fairly small intervals<br />
(very frustrating).<br />
<br />
Example: A triangle that should move along a sine curve always pointing in<br />
the direction it is going to move next.<br />
</blockquote><br />
<br />
The feature has recently been added to Synfig (23rd September 2007) and will be in the next release.<br />
<br />
== Summary ==<br />
<br />
We're going to:<br />
<br />
* {{l|Following a BLine_(the_very_old_way)#Create the Layers|Draw a curve and an arrow}}<br />
* {{l|Following a BLine_(the_very_old_way)#Make the Arrow Move|Link the arrow's Origin}} to the curve's Vertices' vector position so the arrow follows the curve<br />
* {{l|Following a BLine_(the_very_old_way)#Make the Arrow Rotate|Link the arrow's Rotate layer}} to the curve's Vertices' tangent so the arrow rotates with the curve<br />
<br />
== Tutorial ==<br />
<br />
This is a brief tutorial giving an example of how to use it:<br />
<br />
=== Create the Animation ===<br />
<br />
File > New<br />
<br />
Time tab > End Time > 10s > OK<br />
<br />
=== Create the Layers ===<br />
<br />
select the BLine Tool<br />
<br />
enable just the Outline checkbox<br />
<br />
draw a bline that you want the arrow to move along<br />
<br />
select the new bline layer, go to its parameters<br />
<br />
right-click on the vertices parameter and "export" it<br />
it will ask for a name.<br />
<br />
you can use whatever name you like but for this tutorial I'm calling it "path"<br />
<br />
(note that you could have checked the 'auto export' box in the draw tool, and set the name in the text box at the top of the tool options to save having to chose export from the menu - it doesn't matter which you use)<br />
<br />
switch back to the 'Normal' tool and look in the "Children" dialog.<br />
<br />
expand the ValueBase Nodes and you'll see all the things that have been exported.<br />
<br />
selecting them will allow us to re-use them elsewhere in the animation later<br />
<br />
back in the bline tool, enable Fill and Outline checkboxes in tool options<br />
<br />
draw an arrow or whatever, pointing to the right<br />
<br />
select the outline, hit control-a to select all its ducks except the green position duck<br />
<br />
drag the ducks so that the arrow is centred around the green position duck<br />
<br />
add a rotate layer above the outline and region<br />
<br />
encapsulate the rotate, outline, and region layers<br />
<br />
rename the encapsulation layer "arrow"<br />
<br />
so now you've got 2 top-level layers: a curved path, and an encapsulation containing an arrow and a rotate layer<br />
<br />
=== Make the Arrow Move ===<br />
<br />
select the "arrow" encapsulation layer<br />
<br />
we want this layer to move along the "path" bline. the Origin parameter of an encapsulation layer can be used to move everything it contains<br />
right-click the Origin parameter and select {{l|Convert#BLine_Vector|Convert > BLine Vertex}}<br />
the Origin parameter will now be expandable - click the small triangle to its left to expand it<br />
<br />
the Origin of the "arrow" layer is now defined by 3 sub parameters: a BLine, the amount to travel along the BLine, and a checkbox that we'll ignore for now.<br />
in the Children dialog, select the "path" ValueNode<br />
<br />
then in the Params dialog, right-click on the "arrow" layer's BLine sub-parameter and "Connect" it to the selected "path" value<br />
<br />
the arrow will move so that it is about half-way along the BLine path (because the Amount sub-parameter defaults to 0.5).<br />
<br />
edit the Amount sub parameter to 0 and to 1, and see the arrow moves to one end of the path and then the other.<br />
<br />
the "Loop" sub parameter determines what happens if you use a value outside the range 0-1 for the Amount. If "Loop" isn't checked, values less than 0 count as 0 and values greater than 1 count as 1. If "Loop" is checked, the value wraps around, so Amounts of 2.4, 1.4, 0.4, -0.6, -1.6, etc all act the same.<br />
<br />
So we've got the arrow moving along the line, but only if we manually edit the Amount parameter. Let's get it to move automatically, by converting the constant Amount parameter into a linearly changing value.<br />
<br />
Right-click the Amount parameter, and Convert it to Linear. This adds sub parameters Rate (how fast the value goes up, per second) and Offset (what value it has at time zero).<br />
<br />
Set Rate to 0.1 and Offset to 0. That will make the value of Amount be 0 at time 0 and 1 at time 10s, so the arrow will move from one end of the line to the other throughout the course of the animation.<br />
<br />
This linearly changing value of the Amount parameter will be useful later on, so let's export it into the Children dialog so we can find it easily later. Right-click the Amount parameter and Export it as "engine". I call it "engine" because this is the parameter that drives the animation.<br />
<br />
Try File > Preview or View > Play to watch the animation. If you like, play with the sub-parameters - turn the Rate up to 0.25 and turn on the Loop checkbox and watch the preview again. You'll see that the arrow moves 3 times faster than before, reaching the end of the line after 4 seconds.<br />
<br />
Turning Loop on means that it will then reappear at the start of the line, and keep moving. Not having Loop on would make it stay at the end of the line until the animation stopped.<br />
<br />
Note that instead of using a Convert>Linear conversion to get the Amount sub-parameter to change over time, we could have used the more traditional method of turning on {{l|Animate Editing Mode}} and adjusting the parameter at different points in time. Either way, we can still export the Amount parameter so that we can use it again in the next step.<br />
<br />
=== Make the Arrow Rotate ===<br />
<br />
You'll notice that although the arrow moves along the line, it doesn't rotate to face the direction of travel. But that's what we're going to use the Rotate layer for.<br />
<br />
Open up the "arrow" encapsulation layer and select the Rotate layer inside. <br />
<br />
Right-click the Amount parameter, which specifies the amount to rotate, and Convert it to type {{l|Convert#BLine Tangent|BLine Tangent}}.<br />
<br />
Open up the sub parameters, select the "path" value in the children dialog, and connect it to the rotate layer's BLine sub-parameter, and select the "engine" value in the children dialog and connect it to the rotate layer's Amount sub-parameter.<br />
<br />
Now watch the preview and you'll see that the arrow is moving along the line, rotating to face the way it's traveling.<br />
<br />
== Results ==<br />
<br />
This is the animation I ended up with: {{l|Media:Arrow-follows-line-tut.sifz|arrow-follows-line-tut.sifz}}<br />
<br />
== Commentary on the Feature ==<br />
<br />
I've noticed that if Loop is on, and amount is 1.0, then it acts as if amount is 0.0, ie. the arrow jumps back to the beginning of the line in the last frame.<br />
<br />
Also, the arrow takes the same time to move along each segment of the bline. So if there's a long straight part then a bendy complex part, the arrow will move much faster along the straight parts (since there will be less vertices in that part).<br />
<br />
It would be good to have the option of having the arrow move at constant speed along the length of the curve.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Following_a_BLine_(the_very_old_way)&diff=19968Following a BLine (the very old way)2015-01-02T11:38:14Z<p>Ciaran: replace normal links with template:L</p>
<hr />
<div><!-- Page info --><br />
{{Title|Following a BLine (the very old way)}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
<!-- Page info end --><br />
<br />
:'''Out-of-date:''' This tutorial has been replaced by {{l|Doc:Following a Spline}}. This out-of-date tutorial is only of interest to people using very old versions of synfig (versions 0.63.05 and earlier). To get the latest version of synfig, see the [http://www.synfig.org/cms/en/download/stable downloads page]. {{l|cow}}<br />
:BLine has been renamed Spline and other [http://www.synfig.org/cms/en/news/terminology-rewrite-sprint/ terminology has changed].<br />
<br />
== Introduction ==<br />
<br />
This is only a rough draft. The content should be OK, but it needs tidying up and could really benefit from some screen shots. If you follow the tutorial, please consider taking some shots as you do so and uploading them here...<br />
<br />
[http://sourceforge.net/tracker/index.php?func=detail&aid=1781903&group_id=144022&atid=757419 This bug report] suggested a feature:<br />
<br />
<blockquote><br />
I would like to be able to draw a bline with N vertices and have<br />
a shape move along that bline (the whole shape or individual vertices).<br />
Currently the only way I have found to do what I want is to draw a bline,<br />
and then move a shape along that line manually at fairly small intervals<br />
(very frustrating).<br />
<br />
Example: A triangle that should move along a sine curve always pointing in<br />
the direction it is going to move next.<br />
</blockquote><br />
<br />
The feature has recently been added to Synfig (23rd September 2007) and will be in the next release.<br />
<br />
== Summary ==<br />
<br />
We're going to:<br />
<br />
* {{l|Following a BLine_(the_very_old_way)#Create the Layers|Draw a curve and an arrow}}<br />
* {{l|Following a BLine_(the_very_old_way)#Make the Arrow Move|Link the arrow's Origin}} to the curve's Vertices' vector position so the arrow follows the curve<br />
* {{l|Following a BLine_(the_very_old_way)#Make the Arrow Rotate|Link the arrow's Rotate layer}} to the curve's Vertices' tangent so the arrow rotates with the curve<br />
<br />
== Tutorial ==<br />
<br />
This is a brief tutorial giving an example of how to use it:<br />
<br />
=== Create the Animation ===<br />
<br />
File > New<br />
<br />
Time tab > End Time > 10s > OK<br />
<br />
=== Create the Layers ===<br />
<br />
select the BLine Tool<br />
<br />
enable just the Outline checkbox<br />
<br />
draw a bline that you want the arrow to move along<br />
<br />
select the new bline layer, go to its parameters<br />
<br />
right-click on the vertices parameter and "export" it<br />
it will ask for a name.<br />
<br />
you can use whatever name you like but for this tutorial I'm calling it "path"<br />
<br />
(note that you could have checked the 'auto export' box in the draw tool, and set the name in the text box at the top of the tool options to save having to chose export from the menu - it doesn't matter which you use)<br />
<br />
switch back to the 'Normal' tool and look in the "Children" dialog.<br />
<br />
expand the ValueBase Nodes and you'll see all the things that have been exported.<br />
<br />
selecting them will allow us to re-use them elsewhere in the animation later<br />
<br />
back in the bline tool, enable Fill and Outline checkboxes in tool options<br />
<br />
draw an arrow or whatever, pointing to the right<br />
<br />
select the outline, hit control-a to select all its ducks except the green position duck<br />
<br />
drag the ducks so that the arrow is centred around the green position duck<br />
<br />
add a rotate layer above the outline and region<br />
<br />
encapsulate the rotate, outline, and region layers<br />
<br />
rename the encapsulation layer "arrow"<br />
<br />
so now you've got 2 top-level layers: a curved path, and an encapsulation containing an arrow and a rotate layer<br />
<br />
=== Make the Arrow Move ===<br />
<br />
select the "arrow" encapsulation layer<br />
<br />
we want this layer to move along the "path" bline. the Origin parameter of an encapsulation layer can be used to move everything it contains<br />
right-click the Origin parameter and select {{l|Convert#BLine_Vector|Convert > BLine Vertex}}<br />
the Origin parameter will now be expandable - click the small triangle to its left to expand it<br />
<br />
the Origin of the "arrow" layer is now defined by 3 sub parameters: a BLine, the amount to travel along the BLine, and a checkbox that we'll ignore for now.<br />
in the Children dialog, select the "path" ValueNode<br />
<br />
then in the Params dialog, right-click on the "arrow" layer's BLine sub-parameter and "Connect" it to the selected "path" value<br />
<br />
the arrow will move so that it is about half-way along the BLine path (because the Amount sub-parameter defaults to 0.5).<br />
<br />
edit the Amount sub parameter to 0 and to 1, and see the arrow moves to one end of the path and then the other.<br />
<br />
the "Loop" sub parameter determines what happens if you use a value outside the range 0-1 for the Amount. If "Loop" isn't checked, values less than 0 count as 0 and values greater than 1 count as 1. If "Loop" is checked, the value wraps around, so Amounts of 2.4, 1.4, 0.4, -0.6, -1.6, etc all act the same.<br />
<br />
So we've got the arrow moving along the line, but only if we manually edit the Amount parameter. Let's get it to move automatically, by converting the constant Amount parameter into a linearly changing value.<br />
<br />
Right-click the Amount parameter, and Convert it to Linear. This adds sub parameters Rate (how fast the value goes up, per second) and Offset (what value it has at time zero).<br />
<br />
Set Rate to 0.1 and Offset to 0. That will make the value of Amount be 0 at time 0 and 1 at time 10s, so the arrow will move from one end of the line to the other throughout the course of the animation.<br />
<br />
This linearly changing value of the Amount parameter will be useful later on, so let's export it into the Children dialog so we can find it easily later. Right-click the Amount parameter and Export it as "engine". I call it "engine" because this is the parameter that drives the animation.<br />
<br />
Try File > Preview or View > Play to watch the animation. If you like, play with the sub-parameters - turn the Rate up to 0.25 and turn on the Loop checkbox and watch the preview again. You'll see that the arrow moves 3 times faster than before, reaching the end of the line after 4 seconds.<br />
<br />
Turning Loop on means that it will then reappear at the start of the line, and keep moving. Not having Loop on would make it stay at the end of the line until the animation stopped.<br />
<br />
Note that instead of using a Convert>Linear conversion to get the Amount sub-parameter to change over time, we could have used the more traditional method of turning on {{l|Animate Editing Mode}} and adjusting the parameter at different points in time. Either way, we can still export the Amount parameter so that we can use it again in the next step.<br />
<br />
=== Make the Arrow Rotate ===<br />
<br />
You'll notice that although the arrow moves along the line, it doesn't rotate to face the direction of travel. But that's what we're going to use the Rotate layer for.<br />
<br />
Open up the "arrow" encapsulation layer and select the Rotate layer inside. <br />
<br />
Right-click the Amount parameter, which specifies the amount to rotate, and Convert it to type {{l|Convert#BLine Tangent|BLine Tangent}}.<br />
<br />
Open up the sub parameters, select the "path" value in the children dialog, and connect it to the rotate layer's BLine sub-parameter, and select the "engine" value in the children dialog and connect it to the rotate layer's Amount sub-parameter.<br />
<br />
Now watch the preview and you'll see that the arrow is moving along the line, rotating to face the way it's traveling.<br />
<br />
== Results ==<br />
<br />
This is the animation I ended up with: {{l|Media:Arrow-follows-line-tut.sifz|arrow-follows-line-tut.sifz}}<br />
<br />
== Commentary on the Feature ==<br />
<br />
I've noticed that if Loop is on, and amount is 1.0, then it acts as if amount is 0.0, ie. the arrow jumps back to the beginning of the line in the last frame.<br />
<br />
Also, the arrow takes the same time to move along each segment of the bline. So if there's a long straight part then a bendy complex part, the arrow will move much faster along the straight parts (since there will be less vertices in that part).<br />
<br />
It would be good to have the option of having the arrow move at constant speed along the length of the curve.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19967Talk:Main Page2014-12-31T18:32:59Z<p>Ciaran: /* Dev: Doc: .... namespaces are they useful? */ I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. ~~~~</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
::::::Hacking MediaWiki will take a full day or two, plus another day later for bug fixing, and then you'd have to maintain the patch for all future upgrades. That's a lot of work if you're busy.<br />
::::::There are lots of ways to logically separate things. You could include a template in all dev articles causing them to be in one category and to display "this is a dev article" at the top.<br />
::::::I think MediaWiki's namespaces feature is the wrong tool for this job. Categories are probably enough (or close enough), and they don't cause any unusual behaviour. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 18:32, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19964Talk:Main Page2014-12-31T17:37:14Z<p>Ciaran: /* Can template:title and template:category be deprecated? */ ::I understand now the purpose of template:title but I don't understand the purpose of template:category (or template:L). ~~~~</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::I understand now the purpose of [[template:title]] but I don't understand the purpose of [[template:category]] (or [[template:L]]). [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:37, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19963Talk:Main Page2014-12-31T17:25:18Z<p>Ciaran: /* Suggestion: use lower case for page titles */ syntax</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be <nowiki>{{title|New Layer Defaults}}</nowiki>. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:: Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19962Talk:Main Page2014-12-31T17:23:22Z<p>Ciaran: I don't understand how template:L helps. And I don't see any explanation on Meta:Template_Style_And_Syntax. People trying to understand this strange link syntax will go to template:L, so there should be documentation there, or a link to docu</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
:--[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
::I understand how [[template:title]] helps with localisation but I don't understand how [[template:L]] helps. And I don't see any explanation on [[Meta:Template_Style_And_Syntax]]. People trying to understand this strange link syntax will go to [[template:L]], so there should be documentation there, or a link to documentation. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
:P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
::That would be fixed by your [[template:title]]. The page could be "new layer defaults" and at the top of the page could be {{title|New Layer Defaults}}. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:23, 31 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:: Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19961Talk:Main Page2014-12-31T17:10:33Z<p>Ciaran: /* Can template:title and template:category be deprecated? */ ::Ok, but that should be documented on template:title. That's where new wiki contributors will look for documentation about that template. ~~~~</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
* --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC) Hello, Ciaran. IMy name is Konstantin Dmitriev, I am an administrator of Synfig Wiki. Please do not replace [[template:L]] and <nowiki>{{l|Cow|cow}}</nowiki> notation - they have a special purpose. As you probably noticed, this wiki have a support of localization to multiple languages. The special "L" template makes it possible to have language pages automatically display they titles in proper language. All those "anomalies" are documented at this page - [[Meta:Template_Style_And_Syntax]]. THe special templates, like "L", "Title" and others make the localization mechanic work on this wiki. In the future we plan to migrate to other mechanism (powered by "Transifex:Live") and then we will be able to switch back to "regular" notations and remove the special templates. But until then, please follow the guides.<br />
* P.S. About the capitalization. Please keep the titles capitalized, because (in my opinion) "new layer defaults" looks worse, comparing to "New Layer Defaults" when displayed in the titles list.<br />
<br />
=== Dev: Doc: .... namespaces are they useful? ===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
::::: The "Doc", "Dev" and other namespaces are intended to logicaly separate the pages. You are welcome to read this page about the structure - [[Meta:Wiki_Structure]]. The search problem you mentioned is an issue, that could be fixed by modifying the MediaWiki behaviour. I was planning to do that, but unfortunaely my time is limited, and I haven't ben able to dig into that yet. you are welcome to submit an issue about that to the special section of [http://www.synfig.org/issues/thebuggenie/synfig/issues/new/issuetype/websiteissue our bugtracker]. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:36, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
:Please read this page about Title template - [[Meta:Template_Style_And_Syntax#Title_template]]. "Category" template provides support for localization mechanism as well. --[[User:Zelgadis|Zelgadis]] ([[User talk:Zelgadis|talk]]) 16:41, 31 December 2014 (UTC)<br />
<br />
::Ok, but that should be documented on [[template:title]]. That's where new wiki contributors will look for documentation about that template. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 17:10, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19958Talk:Main Page2014-12-31T10:21:04Z<p>Ciaran: /* Dev: Doc: .... namespaces are they useful ?= */ I see two reasons to get rid of "Dev:"</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
=== Dev: Doc: .... namespaces are they useful ?===<br />
<br />
Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
::: Yep "Doc:" prefix could be remove in some cases.... but not "Dev:" ones ! --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:52, 31 December 2014 (UTC)<br />
::::Are there cases where "Doc:" shouldn't be removed?<br />
::::I see two reasons to get rid of "Dev:". One is that, if someone comes to the wiki and types "coding conventions" into the search box, there is no advantage in ''not'' showing them "[[Dev:Coding Conventions]]" in the results. The other is that, if someone comes to the wiki looking for developer documentation, there is no way for them to know that they have to go to advanced search and enable the Dev namespace if they want developer documentation.<br />
::::I can see theoretical justifications for separating the pages, but the namespaces feature of MediaWiki is not a good way to do this. The solution is worse than the problem. (Maybe there is no good way to do this using MediaWiki.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 10:21, 31 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Following_a_BLine_(the_very_old_way)&diff=19956Following a BLine (the very old way)2014-12-31T09:36:58Z<p>Ciaran: formatting</p>
<hr />
<div><!-- Page info --><br />
{{Title|Following a BLine (the very old way)}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
<!-- Page info end --><br />
<br />
:'''Out-of-date:''' This tutorial has been replaced by [[Doc:Following a Spline]]. This out-of-date tutorial is only of interest to people using very old versions of synfig (versions 0.63.05 and earlier). To get the latest version of synfig, see the [http://www.synfig.org/cms/en/download/stable downloads page].<br />
:BLine has been renamed Spline and other [http://www.synfig.org/cms/en/news/terminology-rewrite-sprint/ terminology has changed].<br />
<br />
== Introduction ==<br />
<br />
This is only a rough draft. The content should be OK, but it needs tidying up and could really benefit from some screen shots. If you follow the tutorial, please consider taking some shots as you do so and uploading them here...<br />
<br />
[http://sourceforge.net/tracker/index.php?func=detail&aid=1781903&group_id=144022&atid=757419 This bug report] suggested a feature:<br />
<br />
<blockquote><br />
I would like to be able to draw a bline with N vertices and have<br />
a shape move along that bline (the whole shape or individual vertices).<br />
Currently the only way I have found to do what I want is to draw a bline,<br />
and then move a shape along that line manually at fairly small intervals<br />
(very frustrating).<br />
<br />
Example: A triangle that should move along a sine curve always pointing in<br />
the direction it is going to move next.<br />
</blockquote><br />
<br />
The feature has recently been added to Synfig (23rd September 2007) and will be in the next release.<br />
<br />
== Summary ==<br />
<br />
We're going to:<br />
<br />
* [[Following a BLine_(the_very_old_way)#Create the Layers|Draw a curve and an arrow]]<br />
* [[Following a BLine_(the_very_old_way)#Make the Arrow Move|Link the arrow's Origin]] to the curve's Vertices' vector position so the arrow follows the curve<br />
* [[Following a BLine_(the_very_old_way)#Make the Arrow Rotate|Link the arrow's Rotate layer]] to the curve's Vertices' tangent so the arrow rotates with the curve<br />
<br />
== Tutorial ==<br />
<br />
This is a brief tutorial giving an example of how to use it:<br />
<br />
=== Create the Animation ===<br />
<br />
File > New<br />
<br />
Time tab > End Time > 10s > OK<br />
<br />
=== Create the Layers ===<br />
<br />
select the BLine Tool<br />
<br />
enable just the Outline checkbox<br />
<br />
draw a bline that you want the arrow to move along<br />
<br />
select the new bline layer, go to its parameters<br />
<br />
right-click on the vertices parameter and "export" it<br />
it will ask for a name.<br />
<br />
you can use whatever name you like but for this tutorial I'm calling it "path"<br />
<br />
(note that you could have checked the 'auto export' box in the draw tool, and set the name in the text box at the top of the tool options to save having to chose export from the menu - it doesn't matter which you use)<br />
<br />
switch back to the 'Normal' tool and look in the "Children" dialog.<br />
<br />
expand the ValueBase Nodes and you'll see all the things that have been exported.<br />
<br />
selecting them will allow us to re-use them elsewhere in the animation later<br />
<br />
back in the bline tool, enable Fill and Outline checkboxes in tool options<br />
<br />
draw an arrow or whatever, pointing to the right<br />
<br />
select the outline, hit control-a to select all its ducks except the green position duck<br />
<br />
drag the ducks so that the arrow is centred around the green position duck<br />
<br />
add a rotate layer above the outline and region<br />
<br />
encapsulate the rotate, outline, and region layers<br />
<br />
rename the encapsulation layer "arrow"<br />
<br />
so now you've got 2 top-level layers: a curved path, and an encapsulation containing an arrow and a rotate layer<br />
<br />
=== Make the Arrow Move ===<br />
<br />
select the "arrow" encapsulation layer<br />
<br />
we want this layer to move along the "path" bline. the Origin parameter of an encapsulation layer can be used to move everything it contains<br />
right-click the Origin parameter and select [[Convert#BLine_Vector|Convert > BLine Vertex]]<br />
the Origin parameter will now be expandable - click the small triangle to its left to expand it<br />
<br />
the Origin of the "arrow" layer is now defined by 3 sub parameters: a BLine, the amount to travel along the BLine, and a checkbox that we'll ignore for now.<br />
in the Children dialog, select the "path" ValueNode<br />
<br />
then in the Params dialog, right-click on the "arrow" layer's BLine sub-parameter and "Connect" it to the selected "path" value<br />
<br />
the arrow will move so that it is about half-way along the BLine path (because the Amount sub-parameter defaults to 0.5).<br />
<br />
edit the Amount sub parameter to 0 and to 1, and see the arrow moves to one end of the path and then the other.<br />
<br />
the "Loop" sub parameter determines what happens if you use a value outside the range 0-1 for the Amount. If "Loop" isn't checked, values less than 0 count as 0 and values greater than 1 count as 1. If "Loop" is checked, the value wraps around, so Amounts of 2.4, 1.4, 0.4, -0.6, -1.6, etc all act the same.<br />
<br />
So we've got the arrow moving along the line, but only if we manually edit the Amount parameter. Let's get it to move automatically, by converting the constant Amount parameter into a linearly changing value.<br />
<br />
Right-click the Amount parameter, and Convert it to Linear. This adds sub parameters Rate (how fast the value goes up, per second) and Offset (what value it has at time zero).<br />
<br />
Set Rate to 0.1 and Offset to 0. That will make the value of Amount be 0 at time 0 and 1 at time 10s, so the arrow will move from one end of the line to the other throughout the course of the animation.<br />
<br />
This linearly changing value of the Amount parameter will be useful later on, so let's export it into the Children dialog so we can find it easily later. Right-click the Amount parameter and Export it as "engine". I call it "engine" because this is the parameter that drives the animation.<br />
<br />
Try File > Preview or View > Play to watch the animation. If you like, play with the sub-parameters - turn the Rate up to 0.25 and turn on the Loop checkbox and watch the preview again. You'll see that the arrow moves 3 times faster than before, reaching the end of the line after 4 seconds.<br />
<br />
Turning Loop on means that it will then reappear at the start of the line, and keep moving. Not having Loop on would make it stay at the end of the line until the animation stopped.<br />
<br />
Note that instead of using a Convert>Linear conversion to get the Amount sub-parameter to change over time, we could have used the more traditional method of turning on [[Animate Editing Mode]] and adjusting the parameter at different points in time. Either way, we can still export the Amount parameter so that we can use it again in the next step.<br />
<br />
=== Make the Arrow Rotate ===<br />
<br />
You'll notice that although the arrow moves along the line, it doesn't rotate to face the direction of travel. But that's what we're going to use the Rotate layer for.<br />
<br />
Open up the "arrow" encapsulation layer and select the Rotate layer inside. <br />
<br />
Right-click the Amount parameter, which specifies the amount to rotate, and Convert it to type [[Convert#BLine Tangent|BLine Tangent]].<br />
<br />
Open up the sub parameters, select the "path" value in the children dialog, and connect it to the rotate layer's BLine sub-parameter, and select the "engine" value in the children dialog and connect it to the rotate layer's Amount sub-parameter.<br />
<br />
Now watch the preview and you'll see that the arrow is moving along the line, rotating to face the way it's traveling.<br />
<br />
== Results ==<br />
<br />
This is the animation I ended up with: [[Media:Arrow-follows-line-tut.sifz|arrow-follows-line-tut.sifz]]<br />
<br />
== Commentary on the Feature ==<br />
<br />
I've noticed that if Loop is on, and amount is 1.0, then it acts as if amount is 0.0, ie. the arrow jumps back to the beginning of the line in the last frame.<br />
<br />
Also, the arrow takes the same time to move along each segment of the bline. So if there's a long straight part then a bendy complex part, the arrow will move much faster along the straight parts (since there will be less vertices in that part).<br />
<br />
It would be good to have the option of having the arrow move at constant speed along the length of the curve.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19955Talk:Main Page2014-12-31T09:17:55Z<p>Ciaran: /* Are tracking a b-line and following a curve functionally the same thing? */ ::Thanks for clarifying. I've updated the intro of those three pages now. ~~~~</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].)<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)<br />
<br />
::Thanks for clarifying. I've updated the intro of those three pages now. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:17, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Following_a_BLine_(the_very_old_way)&diff=19954Following a BLine (the very old way)2014-12-31T09:16:46Z<p>Ciaran: clarify note about versions of this tutorial</p>
<hr />
<div><!-- Page info --><br />
{{Title|Following a BLine (the very old way)}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
<!-- Page info end --><br />
<br />
;'''Important NOTE''': This tutorial has been replaced by [[Doc:Following a Spline]]. This out-of-date tutorial is only of interest to people using very old versions of synfig (versions 0.63.05 and earlier). To get the latest version of synfig, see the [http://www.synfig.org/cms/en/download/stable downloads page].<br /> BLine has been renamed Spline and other [http://www.synfig.org/cms/en/news/terminology-rewrite-sprint/ terminology has changed].<br />
<br />
== Introduction ==<br />
<br />
This is only a rough draft. The content should be OK, but it needs tidying up and could really benefit from some screen shots. If you follow the tutorial, please consider taking some shots as you do so and uploading them here...<br />
<br />
[http://sourceforge.net/tracker/index.php?func=detail&aid=1781903&group_id=144022&atid=757419 This bug report] suggested a feature:<br />
<br />
<blockquote><br />
I would like to be able to draw a bline with N vertices and have<br />
a shape move along that bline (the whole shape or individual vertices).<br />
Currently the only way I have found to do what I want is to draw a bline,<br />
and then move a shape along that line manually at fairly small intervals<br />
(very frustrating).<br />
<br />
Example: A triangle that should move along a sine curve always pointing in<br />
the direction it is going to move next.<br />
</blockquote><br />
<br />
The feature has recently been added to Synfig (23rd September 2007) and will be in the next release.<br />
<br />
== Summary ==<br />
<br />
We're going to:<br />
<br />
* [[Following a BLine_(the_very_old_way)#Create the Layers|Draw a curve and an arrow]]<br />
* [[Following a BLine_(the_very_old_way)#Make the Arrow Move|Link the arrow's Origin]] to the curve's Vertices' vector position so the arrow follows the curve<br />
* [[Following a BLine_(the_very_old_way)#Make the Arrow Rotate|Link the arrow's Rotate layer]] to the curve's Vertices' tangent so the arrow rotates with the curve<br />
<br />
== Tutorial ==<br />
<br />
This is a brief tutorial giving an example of how to use it:<br />
<br />
=== Create the Animation ===<br />
<br />
File > New<br />
<br />
Time tab > End Time > 10s > OK<br />
<br />
=== Create the Layers ===<br />
<br />
select the BLine Tool<br />
<br />
enable just the Outline checkbox<br />
<br />
draw a bline that you want the arrow to move along<br />
<br />
select the new bline layer, go to its parameters<br />
<br />
right-click on the vertices parameter and "export" it<br />
it will ask for a name.<br />
<br />
you can use whatever name you like but for this tutorial I'm calling it "path"<br />
<br />
(note that you could have checked the 'auto export' box in the draw tool, and set the name in the text box at the top of the tool options to save having to chose export from the menu - it doesn't matter which you use)<br />
<br />
switch back to the 'Normal' tool and look in the "Children" dialog.<br />
<br />
expand the ValueBase Nodes and you'll see all the things that have been exported.<br />
<br />
selecting them will allow us to re-use them elsewhere in the animation later<br />
<br />
back in the bline tool, enable Fill and Outline checkboxes in tool options<br />
<br />
draw an arrow or whatever, pointing to the right<br />
<br />
select the outline, hit control-a to select all its ducks except the green position duck<br />
<br />
drag the ducks so that the arrow is centred around the green position duck<br />
<br />
add a rotate layer above the outline and region<br />
<br />
encapsulate the rotate, outline, and region layers<br />
<br />
rename the encapsulation layer "arrow"<br />
<br />
so now you've got 2 top-level layers: a curved path, and an encapsulation containing an arrow and a rotate layer<br />
<br />
=== Make the Arrow Move ===<br />
<br />
select the "arrow" encapsulation layer<br />
<br />
we want this layer to move along the "path" bline. the Origin parameter of an encapsulation layer can be used to move everything it contains<br />
right-click the Origin parameter and select [[Convert#BLine_Vector|Convert > BLine Vertex]]<br />
the Origin parameter will now be expandable - click the small triangle to its left to expand it<br />
<br />
the Origin of the "arrow" layer is now defined by 3 sub parameters: a BLine, the amount to travel along the BLine, and a checkbox that we'll ignore for now.<br />
in the Children dialog, select the "path" ValueNode<br />
<br />
then in the Params dialog, right-click on the "arrow" layer's BLine sub-parameter and "Connect" it to the selected "path" value<br />
<br />
the arrow will move so that it is about half-way along the BLine path (because the Amount sub-parameter defaults to 0.5).<br />
<br />
edit the Amount sub parameter to 0 and to 1, and see the arrow moves to one end of the path and then the other.<br />
<br />
the "Loop" sub parameter determines what happens if you use a value outside the range 0-1 for the Amount. If "Loop" isn't checked, values less than 0 count as 0 and values greater than 1 count as 1. If "Loop" is checked, the value wraps around, so Amounts of 2.4, 1.4, 0.4, -0.6, -1.6, etc all act the same.<br />
<br />
So we've got the arrow moving along the line, but only if we manually edit the Amount parameter. Let's get it to move automatically, by converting the constant Amount parameter into a linearly changing value.<br />
<br />
Right-click the Amount parameter, and Convert it to Linear. This adds sub parameters Rate (how fast the value goes up, per second) and Offset (what value it has at time zero).<br />
<br />
Set Rate to 0.1 and Offset to 0. That will make the value of Amount be 0 at time 0 and 1 at time 10s, so the arrow will move from one end of the line to the other throughout the course of the animation.<br />
<br />
This linearly changing value of the Amount parameter will be useful later on, so let's export it into the Children dialog so we can find it easily later. Right-click the Amount parameter and Export it as "engine". I call it "engine" because this is the parameter that drives the animation.<br />
<br />
Try File > Preview or View > Play to watch the animation. If you like, play with the sub-parameters - turn the Rate up to 0.25 and turn on the Loop checkbox and watch the preview again. You'll see that the arrow moves 3 times faster than before, reaching the end of the line after 4 seconds.<br />
<br />
Turning Loop on means that it will then reappear at the start of the line, and keep moving. Not having Loop on would make it stay at the end of the line until the animation stopped.<br />
<br />
Note that instead of using a Convert>Linear conversion to get the Amount sub-parameter to change over time, we could have used the more traditional method of turning on [[Animate Editing Mode]] and adjusting the parameter at different points in time. Either way, we can still export the Amount parameter so that we can use it again in the next step.<br />
<br />
=== Make the Arrow Rotate ===<br />
<br />
You'll notice that although the arrow moves along the line, it doesn't rotate to face the direction of travel. But that's what we're going to use the Rotate layer for.<br />
<br />
Open up the "arrow" encapsulation layer and select the Rotate layer inside. <br />
<br />
Right-click the Amount parameter, which specifies the amount to rotate, and Convert it to type [[Convert#BLine Tangent|BLine Tangent]].<br />
<br />
Open up the sub parameters, select the "path" value in the children dialog, and connect it to the rotate layer's BLine sub-parameter, and select the "engine" value in the children dialog and connect it to the rotate layer's Amount sub-parameter.<br />
<br />
Now watch the preview and you'll see that the arrow is moving along the line, rotating to face the way it's traveling.<br />
<br />
== Results ==<br />
<br />
This is the animation I ended up with: [[Media:Arrow-follows-line-tut.sifz|arrow-follows-line-tut.sifz]]<br />
<br />
== Commentary on the Feature ==<br />
<br />
I've noticed that if Loop is on, and amount is 1.0, then it acts as if amount is 0.0, ie. the arrow jumps back to the beginning of the line in the last frame.<br />
<br />
Also, the arrow takes the same time to move along each segment of the bline. So if there's a long straight part then a bendy complex part, the arrow will move much faster along the straight parts (since there will be less vertices in that part).<br />
<br />
It would be good to have the option of having the arrow move at constant speed along the length of the curve.</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Tracking_Curves&diff=19953Tracking Curves2014-12-31T09:12:13Z<p>Ciaran: :Note: There is a newer tutorial for this topic at Doc:Following a Spline, however, some info from this tutorial such as link/export hasn't yet been added to the new tutorial. There is also another [[Following a BLine (the very old way)|''very'' out</p>
<hr />
<div><!-- Page info --><br />
{{Title|Tracking Curves}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
<br />
:Note: There is a newer tutorial for this topic at [[Doc:Following a Spline]], however, some info from this tutorial such as link/export hasn't yet been added to the new tutorial. There is also another [[Following a BLine (the very old way)|''very'' out-of-date tutorial]] for synfig 0.61.08.<br />
<br />
== Introduction ==<br />
[[File:Track-Curve-tutorial-Follow-bline.gif|frame|left|Extract of Follow-bline as animated gif / 3s - 210ko / ffmpeg -i + gimp resize/export]]<br />
[http://uk.youtube.com/watch?v=wJ7C-FcxAy0 YouTube] | <br />
{{l|Media:Follow-bline.sifz|follow-bline.sifz}} | [http://dooglus.rincevent.net/synfig/follow-bline.avi follow-bline.avi]<br />
<br />
<br />
The above example links show an animation in which a layer follows a moving curve, and rotates to follow the curve as it moves.<br />
<br />
How was that achieved? It's currently quite complicated to set up an arrangement like this in Synfig Studio, so I'll describe here how it works.<br />
<br />
== Discussion ==<br />
<br />
If you download the .sifz file and load it into Synfig Studio, it really isn't easy to see how the effect is achieved.<br />
<br />
When this animation was created (in 2007), it was possible to make a layer track a curve with just 2 points, but not to get it to track a general curve.<br />
<br />
Since then, new {{l|Convert|conversion types}} called "{{l|Convert#Spline Vector|Spline Vector}}" and "{{l|Convert#Spline Tangent|Spline Tangent}}" have been added to Synfig, and so tracking a general {{Literal|Spline}} is now possible. See {{l|Doc:Following a Spline|this tutorial}} for an example.<br />
<br />
== Details ==<br />
<br />
=== Overview ===<br />
<br />
The animation lasts for 32 seconds and has 3 top-level layers. This is a very simple animation other than the two parts with links (below), which control the location of the moving blob and the shape of the white beam of light respectively. These two parts are described separately.<br />
<br />
The three top-level layers are as follows:<br />
<br />
<blockquote><br />
<br />
==== top-level layer 1: moving blob ====<br />
<br />
An {{l|Group|group}} of three layers. Its origin is {{l|Connect|connected}} to the {{l|Export|exported}} {{l|ValueNode}} "{{l|Tracking Curves#Moving Point|moving point}}". The three {{l|Layers|layers}} are:<br />
* direction of movement - The fuzzy white beam of light. This is a simple spline with a feather of 0.3 units to make it fuzzy. Its vertices are connected to the {{l|ValueNode}} called "{{l|Tracking Curves#Beam of Light|beam of light}}".<br />
* inner circle - The smaller yellow circle. Not animated at all.<br />
* outer circle - The larger red circle. Not animated at all.<br />
<br />
Note the technique here. I could have animated both of the two circles and the beam all separately, but it is much simpler to group them into a single Group layer and animate the position of that instead.<br />
<br />
==== top-level layer 2: line ====<br />
<br />
The moving curve which the object follows. It has {{l|Waypoints|waypoints}} at 0s, 16s, and 32s to make the line move. I {{l|Export|exported}} four of its animated {{l|ValueNode|ValueNodes}} so that I could use them later to define the curved segment that the blob should follow.<br />
<br />
The exported four {{l|ValueNode|ValueNodes}} are:<br />
* vertex1 - The position of the beginning of the curve<br />
* vertex2 - The position of the end of the curve<br />
* tangent1 - The tangent at the beginning of the curve<br />
* tangent2 - The tangent at the end of the curve<br />
<br />
The moving curve is an {{l|Outline Layer}}, created using the {{l|Spline Tool}}. It only has 2 vertices. Note that the {{l|Spline Tool}} creates layers which have lists of {{l|SplinePoints}} to define the shape of the layer, and that {{l|SplinePoints}} contain more than just vertices and tangents. {{l|SplinePoints}} also have parameters like split tangents', and {{Literal|width}}, which aren't relevant when creating a Segment, so I only exported the four {{l|ValueNode|ValueNodes}} that I needed to create the Segment.<br />
<br />
==== top-level layer 3: black background ====<br />
<br />
A solid black background. Not animated at all.<br />
<br />
</blockquote><br />
<br />
=== Moving Point ===<br />
<br />
The "moving point" {{l|ValueNode}} represents the point on the moving spline where the circles are currently centered. It is an exported ValueNode of type "{{l|Convert#Segment Vertex|Segment Vertex}}". It has 2 components which determine the vertex that is used as its value:<br />
* segment - this uses the ValueNode called "{{l|Tracking Curves#Spline|spline}}"<br />
* amount - this uses the ValueNode called "{{l|Tracking Curves#Spline Parameter|spline parameter}}"<br />
<br />
=== Beam of Light ===<br />
<br />
The "beam of light" ValueNode is a two-point spline, with vertices as follows:<br />
* Vertex001 - This is the vertex at the center of the circle. It doesn't need to move, since the circles don't move. What moves is the "moving blob" layer, the {{l|Group|group}} layer which contains this line and the two circles. So this vertex has a constant position of (0,0)<br />
* Vertex002 - This is the other end of the fuzzy white beam. It was a width of 5 units to make the beam diverge. Its position is connected to the ValueNode called "{{l|Tracking Curves#Scaled Tangent|scaled tangent}}".<br />
<br />
=== Scaled Tangent ===<br />
<br />
The "scaled tangent" ValueNode is the offset vector from the center of the circles to the wide end of the beam of light.<br />
<br />
This offset needs to be a vector in a direction parallel to the tangent to the moving curve at the current point. This was achieved using the Scale convert type, with 2 sub parameters:<br />
* Link - This is the vector to scale. It is a vector representing the tangent to the moving curve at the current position of the circles, and so I called it "tangent". This is arrived at using the {{l|Convert#Segment Tangent|Segment Tangent}} conversion type, which has two sub-parameters:<br />
** Segment - this re-uses the ValueNode called "{{l|Tracking Curves#Spline|spline}}"<br />
** Amount - this re-uses the ValueNode called "{{l|Tracking Curves#Spline Parameter|spline parameter}}"<br />
* Scalar - This is the amount to scale it by. Spline curves have tangents which point from the start vertex towards the end vertex, along the curve. I want my beam of light to point in the direction of travel, which is sometimes towards the start of the curve and sometimes towards the end. To do this I needed to multiply the "tangent" ValueNode above by a number which would be negative when traveling towards the start of the curve. It just so happens that sin(angle+90) has exactly that property, and also has the benefit of making the beam get longer as the movement speeds up. So I called this ValueNode "(sin(angle+90))" and defined it as a "Sine" convert type, defined as value=Amplitude*sin(Angle):<br />
** Angle - This needs to be "Angle+90", so it's defined as a subtraction (Synfig has a 'subtract' convert type, but no add). value = LHS-RHS:<br />
*** LHS - The left hand side of the subtraction - this is connected to "{{l|Tracking Curves#Linearly Changing Angle|linearly changing angle}}"<br />
*** RHS - The right hand side of the subtraction. It's a constant -90.<br />
** Amplitude - This is a constant 0.4, which simply scales the length of the beam of light down to keep it mostly on the screen.<br />
<br />
=== Spline ===<br />
<br />
The "spline" ValueNode is a segment representing the curve to follow. It connects to the vertex1, vertex2, tangent1, and tangent2 ValueNodes, as exported from the '{{l|Tracking Curves#top-level layer 2: line|line}}' layer above.<br />
<br />
=== Spline Parameter ===<br />
<br />
The "Spline parameter" ValueNode is number ranging from 0 to 1, which indicates how far along the segment to go. 0 means "use vertex1" and 1 means "use vertex2".<br />
<br />
I want the point to travel along the curve [http://en.wikipedia.org/wiki/Sinusoidal sinusoidally], meaning it will travel fastest in the middle and slow to a momentary stop at either end. This makes the movement look smoother than using a linear movement.<br />
<br />
The sin() function returns a number between -1 and 1, and I want a value between 0 and 1, so I halve the sin() value, giving -0.5 to 0.5, then add 0.5 to it, giving 0 to 1.<br />
<br />
Consequently, this 'spline parameter' value is the result of a subtraction, LHS-RHS:<br />
* LHS - The left hand side of the subtraction. I called this ValueNode "((sin(angle))/2). This will range from -0.5 to 0.5, and is the result of the '{{l|Convert#Sine|sine}}' convert type, sin(Angle)*Amplitude:<br />
** Angle - This is connected to "{{l|Tracking Curves#Linearly Changing Angle|linearly changing angle}}"<br />
** Amplitude - This is used to scale the value. Since I want sin(Angle)/2, the value is a constant 0.5.<br />
* RHS - The right hand side of the subtraction. I wanted to add 0.5 to sin(angle)/2, but synfig only offers subtraction, so I subtracted -0.5 instead, which is the same. Thus, RHS is a constant Real ValueNode, with value -0.5<br />
<br />
=== Linearly Changing Angle ===<br />
<br />
The "linearly changing angle" ValueNode is the constantly changing angle that drives the whole animation. Whenever the angle increases by 360 degrees, the output of sin(Angle) does one complete cycle from 0 -> 1 -> 0 -> -1 -> 0. The angle changes linearly, using the Linear convert type, which has 2 parameters:<br />
* Rate - How many degrees per second to increase. In the animation this is set to a constant value of 45 degrees per second. This means that one complete cycle (from the center to the right end, to the left end, and back to the center) will take 360/45 = 8 seconds to complete. This gives us four complete cycles in the 32 second animation.<br />
* Offset - The value at the beginning of the animation (time = 0). Changing this to 90 for example will make the blob start at the right-hand end of the line. while changing it to 180 will make the blob start in the middle, but facing (and traveling) left.<br />
<br />
== Screen Shot ==<br />
<br />
This screen shot shows all the exported ValueNodes in the top right. Note that a few of them aren't necessary, such as the {{Literal|yellow}}, {{Literal|red}}, and {{Literal|width}} {{l|ValueNodes}}. Well, actually none of them are necessary - it's possible to do the whole animation without exporting anything at all. It would lead to a small amount of duplication, since both the position of the blob and the direction of the light beam are driven by the same angle. But mainly exporting is a way of naming the ValueNodes, which acts as a kind of documentation.<br />
<br />
In the {{l|Parameters_Panel|Parameters}} panel in the bottom left you can see some of the sub-parameters of the '{{l|Tracking Curves#Moving Point|moving point}}' ValueNode.<br />
<br />
<gallery caption="Track Curve screenshots" widths="500px" heights="600px" perrow="2"><br />
File:Track-curve-tutorial-screenshot1.png|{{l|Canvas}} window and {{l|Parameters_Panel|Parameters}} panel.<br />
File:Track-curve-tutorial-screenshot2.png|{{l|Library_Panel|Libray}} and {{l|Layers_Panel|Layers}} panels.<br />
</gallery></div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Doc:Following_a_Spline&diff=19952Doc:Following a Spline2014-12-31T09:10:05Z<p>Ciaran: :Note: There is also a slightly out-of-date tutorial on this topic at Tracking Curves. It contains some info, particularly about link/export, which hasn't yet been added to this new tutorial. There is also another [[Following a BLine (the very old w</p>
<hr />
<div><!-- Page info --><br />
{{Title|Following a Spline}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
:Note: There is also a slightly out-of-date tutorial on this topic at [[Tracking Curves]]. It contains some info, particularly about link/export, which hasn't yet been added to this new tutorial. There is also another [[Following a BLine (the very old way)|very out-of-date tutorial]] for synfig 0.61.08.<br />
== Introduction ==<br />
<br />
This tutorial will demonstrate how to make an object follow the path of an arbitrary curve, rotating to face the direction of travel.<br />
<br />
== Summary ==<br />
<br />
We're going to:<br />
<br />
* {{l|Doc:Following a Spline#Create the Layers|Draw a curve and an arrow}}<br />
* {{l|Doc:Following a Spline#Make the Arrow Move and Rotate|Link the arrow's Origin and Rotation}} to the Spline so the arrow follows the curve<br />
<br />
== Tutorial ==<br />
<br />
This is a brief tutorial giving an example of how to use it:<br />
<br />
=== Create the Animation ===<br />
<br />
File > New<br />
<br />
=== Create the Layers ===<br />
<br />
Select the {{l|Spline Tool}}<br />
[[File:Spline-tool-0.63.06.png|frame|none]]<br />
<br />
enable just the Outline checkbox<br />
<br />
draw a spline that you want the arrow to move along<br />
<br />
click the {{Literal|Make Spline}} icon in the bottom left of the {{l|Tool_Options_Panel}} to create the spline.<br />
<br />
still in the Spline Tool, enable {{Literal|Create Outline}} and {{Literal|Create Region}} checkboxes in tool options<br />
[[File:Spline-Tool-Options_0.63.06.png|frame|center]]<br />
<br />
draw an arrow or whatever, pointing to the right.<br />
<br />
Switch to the {{l|Transform Tool}}<br />
<br />
select the outline, hit control-a to select all its {{l|Handle|handles}} except the green position handle<br />
<br />
drag the handle so that the arrow is centred around the green position handle<br />
<br />
Add a {{l|Rotate Layer}} above the outline and region<br />
<br />
{{l|Group}} the rotate, outline, and region layers<br />
<br />
so now you've got 2 top-level layers: a curved path, and a group containing an arrow and a rotate layer<br />
<br />
=== Make the Arrow Move and Rotate ===<br />
<br />
Select the group layer by clicking it in the {{l|Layers Panel}}<br />
<br />
select its green position handle by clicking on it in the canvas window<br />
<br />
additionally select the Rotate layer by holding Control and clicking it in the Layers panel<br />
<br />
additionally select the blue "rotation amount" handle by holding {{Shortcut|ctrl}} and clicking on it in the canvas window<br />
<br />
so now we should have 2 layers selected, and one handle from each of those 2 layers selected<br />
<br />
now additionally select the curved spline layer (it should be the last layer in the Layer panel's list) by holding {{Shortcut|ctrl}} and clicking on it<br />
<br />
right-click on the dotted line that indicates the position of the curved spline - not on any handle, but on the dotted line between handle<br />
<br />
from the context menu that pops up, select {{Literal|Link to Spline}}<br />
[[Image:Spline-Link-to-0.63.06.png|frame|none]]<br />
<br />
The arrow group should move so that its green position handle is on the spline, and it should rotate so that the arrow points along the spline at that point<br />
<br />
Select just the group layer, and drag its green handle around. you'll see that the handle is constrained now to line on the spline, and that dragging it also affects the rotation of the arrow as expected<br />
<br />
We can now animate the arrow. turn on {{l|Animate_Editing_Mode}} by clicking the icon in the bottom right of the canvas window.<br />
<br />
* at time '''0f''', drag the group layer's green position handle to one end of the spline<br />
* at time '''5s''', drag the same position handle to the other end of the spline<br />
<br />
Try {{c|<Caret Menu>|<File>|Preview|}} to watch the animation.<br />
<br />
== Results ==<br />
<br />
This is the animation I ended up with: <br />
[[File:Arrow-follows-bline.gif|center|alt Following a Spline example]]<br />
<br />
Synfig project : {{l|Media:Arrow-follows-bline.sifz|Arrow-follows-bline.sifz}}<br />
<br />
== Controlling the linear velocity ==<br />
<br />
By default, the arrow travels the whole spline with a constant velocity, independently of the spline structure.<br />
<br />
If you select the group layer and look at the Parameters Panel, then you'll see that its Origin parameter is {{L|convert|converted}} to {{Literal|Spline Vertex}} type. This is done automatically when you do "Link to Spline" action. You can disable the "Homogenous" subparameter and then the speed of the arrow will depend on the spline structure - it will take the same time to move along each segment of the spline. So if there's a long straight part then a bendy complex part, the arrow will move much faster along the straight parts (since there will be less vertices in that part). In physics terms, the linear velocity (that is, the speed over the spline) is not constant.<br />
<br />
For illustration of the "Homogenous" effect see [http://www.youtube.com/watch?v=3PGXroxBcuo this demo].</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19951Talk:Main Page2014-12-31T09:02:42Z<p>Ciaran: /* Suggestion: use lower case for page titles */ ::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I didn't find the page "Doc:Following a Spline". Can you see that this is silly and unhelpful :</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].)<br />
<br />
:'''Dev: Doc:''' are namespaces . Ie , when an (regular) user do a search, it is done on regular pages only, nothing about Dev will come out. I think me must keep namespaces --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 08:25, 31 December 2014 (UTC)<br />
::That's awful! I just confirmed it: I typed "Following a Spline" into the search box, hit [Search], and I ''didn't'' find the page "[[Doc:Following a Spline]]"! Can you see that this is unintuitive and unhelpful :-) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 09:02, 31 December 2014 (UTC)<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)<br />
<br />
* "Following a BLine/Old Way" could be safely be archived i think.... <br />
* "Following Spline" actually state of the doc (ugly formating!)<br />
* "Tracking Curves", i think we can keep it has it explain deeper the use of link/export, maybe this page should focus more on that point. --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 09:01, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Talk:Main_Page&diff=19946Talk:Main Page2014-12-31T08:10:09Z<p>Ciaran: /* Are tracking a b-line and following a curve functionally the same thing? */ new section</p>
<hr />
<div>== New Layout ==<br />
<br />
The new layout does look a lot better, but before deleting the old layout, can we make sure we're not losing any useful links? For example, currently the "Special:Allpages" link is only in the old layout. -- [[User:Dooglus|dooglus]] 12:27, 26 December 2007 (EST)<br />
:We can add al that links in the left bar if you think its ok.<br />
::Yaco<br />
<br />
:I'm personally a fan of the organization of [[http://processing.org processing.org]]<br />
::Bmud<br />
<br />
The 0.61.08 download image needs to say "Synfig Animation Studio" instead of "Synfig"<br />
:[[User:PaulWise|pabs]] 04:27, 6 April 2008 (EDT)<br />
<br />
<br />
I saw there's a way to remove the toolbox for un-connected people, maybe we could do that, as the links in the toolbox are only usefull to connected persons.<br><br />
And then, add the "Sidebar" back to the left side, with much more links in it (like, the ones from the bottom of the main page, that I even removed on the [[Main_Page.fr]]), that would be great. <br><br />
And have a "Topbar" page or just some fixed link for the topbar, with only "Home / About / Download / Gallery / Screenshots / Tutorials / Forums " in a smaller font, and a lighter color (not-visited pages are #2A4D66 on #030336 and they're hardly visible at 1st sight).<br />
:[[User:Rore|Rore]] 02:49, 7 April 2008 (EDT)<br />
<br />
<br />
Upper image overlaps search bar and user menu on 1024x768 screen resolution. Tested with opera. --[[User:AkhIL|AkhIL]] 22:45, 8 April 2008 (EDT)<br />
<br />
There's a thick black nothing between the left hand boxes and the main central page content. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
I'd like to see more links in the left hand boxes - at least "all pages" should be there, and things like "people", "bugs", "press", etc from the top would be better at the side. There are too many links across the top. We should just have the most useful ones there. -- [[User:Dooglus|dooglus]] 15:31, 11 April 2008 (EDT)<br />
<br />
[http://dooglus.rincevent.net/random/mainpage.png] shows some remaining problems:<br />
* the border of the top image is different widths on the two sides<br />
* the text links and search box on the right are hidden by the image<br />
* the image text isn't readable<br />
* the image text mis-spells "beatiful"<br />
<br />
== Website navigation reorganization plan ==<br />
<br />
Ok, let's begin a breakout of all that mess what we have now.<br />
<br />
It's a shame, what synfig.org have website navigation, which confuses not only newbies, but also a community regulars. So, what could we do about that?<br />
<br />
The main problem is the side bar, which contain too much elements scattered around almost without any logic. <br />
<br />
* [[User:Rore|Rore]] : '''It seems you completely forgot the existence of the top bar. It has every element you talk about (Home, About, Download, Screenshot (can be changed by Gallery), Documentation, etc.)''' But as I say a few months ago, the links are too dark to be clearly visible.<br />
<br />
It take a long time to look through all elements and to decide which one you really need. Who is read all elements at the side bar from top to bottom? No one? I guess so. So it should contain minimal count of menu elements and be as intuitive as possible.<br />
<br />
Imagine what you are a person, who visits synfig.org for the first time. He may not ever know what Synfig is all about, so the first thing what you need is the '''[[About]]''' link.<br />
<br />
* NOTE: Why not to place [[Screenshots]] into [[About]] page? Or maybe just place a link to screenshots to about page? It's all related...<br />
** ''Some screenshots in the about page is definitely a good idea. The About link is the 2nd one on top, just after the home - but when links are not visited, their color is too dark to be clearly seen. [[User:Rore|Rore]] 17:14, 20 July 2008 (EDT) ''<br />
<br />
Next, if he read about Synfig is and got interested, the next thing what potential user wants to know is what Synfig capable to do. Here comes the '''[[Gallery]]''' link.<br />
<br />
<br />
* ANOTHER NOTE: Gallery page should be restructured and redesigned. First of all it should be splited int two sections - "Pictures" and "Videos". <br />
** Pictures should be arranged into the table. Each picture should have caption, thumbnail, author credits, and link to the source (if possible).<br />
** Videos also should be arranged into a single table, but one video per row. It should contain thumbnail, caption, author, short description, link to the source (if possible). Also it would be nice to have not only link to youtube version, but to downloadable oggTheora file. <br />
*** [[User:Pxegeek|Pxegeek]] Whilst I support the use of OggTheora, I'm probably one of the few Windows users that can play them. Is MPG/MPG2 sufficiently industry standard to be allowed? I agree that avoiding WMP or QT is preferable. <br />
*** [[User:Zelgadis|Zelgadis]] : MPG/MP2 is proprietary formats. I am not against using them, but it's better to give preference to open formats. With appropriate instructions how to play them.<br />
** All thumbnails should be aligned by size.<br />
** Why we have so few items at the gallery? Why "Cut the circle" is not there? The first thing we should encourage people is to publish their works on the Gallery page!<br />
<br />
OK, inspired by all beautiful art, user wants to try ut the Synfig package. That's right, he goes to '''[[Download]]''' section.<br />
<br />
* NOTE AGAIN: We don't need the 'Contents' at the top of Download page. It takes one third of the whole space! Why is each distribution arranged as heading? Make it a list of items! Why is License and Documentation here?<br />
** [[User:Pxegeek|Pxegeek]] I think you answered your own question - we have contents list because each distro has its own heading. Personally, I'd like to see a separate download page for Linux, Windows & Mac, where we can talk about all the features that are specific to that OS/ binary compilation (e.g. no dv support under windows). <br />
** [[User:Rore|Rore]] : I agree with pixelgeek, about having different pages for the 3 main OS, it will make things clearer for people. However, you can still remove the big Table Of Content at the top by adding __NO TOC__ to the page (without the space - but it's interpreted if I don't add it).<br />
<br />
After downloading and installing Synfig, user suddenly realizes what he is not able to learn it by himself and he needs... '''[[Documentation]]'''!<br />
<br />
After playing with synfig a little more user is makes something what he needs to show up or stucking with a problem which solution he couldn't find in documentation. Then he needs to '''[[Contact]]''' with community. And the '''[[Forums]]''' (cause many people I know don't even aware about IRC).<br />
<br />
After all if user is also a coder and willing to implement all new features that he is missing, or just wants to contribute to code, then he will search for '''[[Development]]''' section.<br />
<br />
What's last? Of course '''[[Get involved!]]'''<br />
<br />
'''About, Gallery, Download, Documentation, Development, Forums, Contact, Development, Get involved''' - is the top level of the navigation hierarchy. Those pages should guide to the less general pages. I.e. [[About]] could guide to [[Screenshots]] and [[Press]], [[Documenation]] could suggest [[Manual]],[[Tutorials]] and [[Reference]]. And so on. Of course this could be not strict hierarchy - i.e. Forums could also appear as a link at the [[Community]] page. Maybe it could be nice to have some [[News]] on the [[Home]] page. <br />
<br />
[[User:Genete|Genete]] ''I think that the main problem is that the side bar (and the top bar) are static. Most of the cool web pages changes its sidebar according to the context they are navigating on the moment. For instance if you're at home page you don't need a "home" link. I would like some sort of expandable side navigation bar that would show the main needed links according on what you're looking for in that moment. if this kind of navigation can be done I suggest something more impacting like:''<br />
<br />
*''What is Synfig?: and its sub links: About, History, Screenshots, Features, Documentation.''<br />
*''What Synfig can do?: Gallery Films, Video, Still, Contests.''<br />
*''I want Synfig!: Download, Build. And a sub section per distro.''<br />
*''Need Help!: Documentation, Forum (include direct links for each section), Contact.''<br />
*''Want to Help?: Development, etc.''<br />
*''(separated section) Toolbox: with all those special links.''<br />
<br />
''The sub menus hierarchy should be expanded a level more when needed. For example for the Documentation entry.''<br />
''And definitively remove the top bar. Ah! and make the left bar translatable!.''<br />
* ''[[User:Zelgadis|Zelgadis]] : I thought about the dynamic sidebar, but is MediaWiki could provide this feature without installing additional extensions? Better to ask pabs3...''<br />
<br />
That's what we placing at the left sidebar at the navigation section. Oh, dooglus asked for the "All pages" link. All that wiki stuff (All pages, Recent changes, Random Page, etc) I suggest to place at the left sidebar too, but in separate section.<br />
<br />
About top of each page. I suggest to remove all that navigation links from top and place there a wiki edit butons - Article, Discussion, Edit, History. Cause with current design it's hard to scroll to the bottom of each page to get access to them. It'll be more friendly to place them on top. <br />
* [[User:Pxegeek|Pxegeek]] - And they don't wrap well on narrow screens - reducing the button count there would be a Good Thing. <br />
* [[User:Genete|Genete]] Yeah duplicate navigation bars is not a good idea. <br />
<br />
Here I exposed my plan of improving the wiki. It could be considered as a roadmap for website development. Suggestions, opinions, oppositions? C'mon, [[People]], don't stay aside! We have a lot of content - now it's time to make it look attractive and respectable!<br />
<br />
== Where should I ask questions about the wiki? ==<br />
<br />
Hi,<br />
<br />
Most wikis have a page for asking questions, making suggestions, and generally discussing how to improve the wiki. A discussion page, or a cafe, or a water cooler, etc. What's the right place on this wiki for general questions and suggestions?<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Actually most of synfig informations are shared by the forum, here the link for doc section [[http://www.synfig.org/forums/viewforum.php?f=25]]<br />
<br />
(I was going to ask what the [[bones]] framework is. The website news makes it sound like an important feature, but there's nothing in the wiki about it.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 02:15, 4 June 2013 (UTC)<br />
* --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 06:21, 4 June 2013 (UTC) Nothing but this one [[Dev:Bone_Layer]] that is not very user friendly... you can copy/organize bones infos from the forum in a nice [[Skeleton_Layer]] page if you want to start documenting it...<br />
<br />
== Suggestion: use lower case for page titles ==<br />
<br />
Page titles on this wiki are sometimes written with a capital letter for each word, and sometimes written in lower case letters. The choice of one style or the other seems to be random, so I'd like to propose a policy: use lower case letters when possible.<br />
<br />
Why? When a page title uses capital letters for each word, it is more difficult to link to it in normal wiki text. Here's an example of linking to a page whose title uses capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[New Layer Defaults|new layer defaults]]</nowiki>.<br />
<br />
or without capitals:<br />
<br />
The dialogue box on the right lets you change the <nowiki>[[new layer defaults]]</nowiki>.<br />
<br />
That said, there are some page titles where capitals are ok such as pages with the name of a synfig concept such as Text Tool. Synfig's text tool is called "Text Tool", and if synfig wants that to be in capital letters then it can be in capital letters. But examples of pages which use generic words and should thus be lower case are:<br />
<br />
* [[Building Documentation]]<br />
* [[Developer Documentation]]<br />
* [[Keyboard Shortcuts]]<br />
* [[Multiplane Camera]]<br />
* [[Parabolic Shot]]<br />
* [[Sewing Splines]]<br />
* [[Subtracting Shapes]]<br />
* [[Tracking Curves]]<br />
* [[Environment Variables]]<br />
* [[Switching Scenes]]<br />
* [[Writer Documentation]]<br />
<br />
Is it ok if I start to change the titles which use generic words and convert them to lower case?<br />
<br />
MediaWiki will automatically make redirect pages for the old page names, so this change will cause absolutely no broken links or other problems.<br />
<br />
(Note: another inconvenience on this wiki is that some pages are prefixed with "Dev:" or "Doc:", which also means that linking to those pages in a normal sentence requires extra syntax. IMO these prefixes are of no help and [[Dev:Coding Conventions]] and [[Doc:Following a Spline]] should be renamed to [[coding conventions]] and [[following a Spline]].)<br />
<br />
(Another inconvenience is that a lot of pages use [[template:L]] for links (<nowiki>{{l|Cow|cow}}</nowiki> instead of the normal <nowiki>[[cow]]</nowiki>), so I'm currently replacing these links with normal links. My goal is to remove anormalities and needless complexity from the wiki in the hope of making it easier for people to contribute.) [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 23:59, 30 December 2014 (UTC)<br />
<br />
== Can [[template:title]] and [[template:category]] be deprecated? ==<br />
<br />
As mentioned above, I'm try to make this wiki easier to contribute to by removing anormalities and needless complexity.<br />
<br />
I've noticed that a lot of pages have a <nowiki>{{title|}}</nowiki> at the top. For example, the page [[FAQ]] has three lines at the top:<br />
<pre><br />
<nowiki><!-- Page info --></nowiki><br />
<nowiki>{{Title|FAQ}}</nowiki><br />
<nowiki><!-- Page info end --></nowiki><br />
</pre><br />
<br />
Does this do anything useful? If not, can I delete them when I see them?<br />
<br />
Similarly, some pages have <nowiki>{{category|}}</nowiki>. For example, [[Canvas Menu Caret]] <nowiki>{{Category|Canvas Window}}</nowiki> at the top. This seems to be just an unusual way to add <nowiki>[[Category:Canvas Window]]</nowiki> to the page. Does it provide any other functionality? If not, I'd like to replace <nowiki>{{Category|Canvas Window}}</nowiki> with <nowiki>[[Category:Canvas Window]]</nowiki> and put them at the end of the article like in normal MediaWiki wikis.<br />
<br />
I'm trying to get rid of unusual syntax so that people familiar with other MediaWiki wikis can contribute to wiki.synfig.org without having to try to understand the unusual syntax. [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 06:00, 31 December 2014 (UTC)<br />
<br />
== Are tracking a b-line and following a curve functionally the same thing? ==<br />
<br />
There are three tutorials:<br />
<br />
* [[Tracking Curves]]<br />
* [[Following a BLine (the very old way)]]<br />
* [[Doc:Following a Spline]]<br />
<br />
I understand that they're not exactly the same thing, but they do have the same goal, and the third tutorial is the most modern way to achieve that goal. Can someone confirm this? [[User:Ciaran|Ciaran]] ([[User talk:Ciaran|talk]]) 08:10, 31 December 2014 (UTC)</div>Ciaranhttps://www.wiki.synfig.org/index.php?title=Tracking_Curves&diff=19945Tracking Curves2014-12-31T07:57:03Z<p>Ciaran: This is functionally the same as "Following a Spline", right? (I think it is, so I wrote that at the top of the article)</p>
<hr />
<div><!-- Page info --><br />
{{Title|Tracking Curves}}<br />
{{Category|Tutorials}}<br />
{{Category|Tutorials Advanced}}<br />
{{NewTerminology}}<br />
<!-- Page info end --><br />
<br />
:A tutorial for a more recent method for this is at [[Doc:Following a Spline]]<br />
<br />
== Introduction ==<br />
[[File:Track-Curve-tutorial-Follow-bline.gif|frame|left|Extract of Follow-bline as animated gif / 3s - 210ko / ffmpeg -i + gimp resize/export]]<br />
[http://uk.youtube.com/watch?v=wJ7C-FcxAy0 YouTube] | <br />
{{l|Media:Follow-bline.sifz|follow-bline.sifz}} | [http://dooglus.rincevent.net/synfig/follow-bline.avi follow-bline.avi]<br />
<br />
<br />
The above example links show an animation in which a layer follows a moving curve, and rotates to follow the curve as it moves.<br />
<br />
How was that achieved? It's currently quite complicated to set up an arrangement like this in Synfig Studio, so I'll describe here how it works.<br />
<br />
== Discussion ==<br />
<br />
If you download the .sifz file and load it into Synfig Studio, it really isn't easy to see how the effect is achieved.<br />
<br />
When this animation was created (in 2007), it was possible to make a layer track a curve with just 2 points, but not to get it to track a general curve.<br />
<br />
Since then, new {{l|Convert|conversion types}} called "{{l|Convert#Spline Vector|Spline Vector}}" and "{{l|Convert#Spline Tangent|Spline Tangent}}" have been added to Synfig, and so tracking a general {{Literal|Spline}} is now possible. See {{l|Doc:Following a Spline|this tutorial}} for an example.<br />
<br />
== Details ==<br />
<br />
=== Overview ===<br />
<br />
The animation lasts for 32 seconds and has 3 top-level layers. This is a very simple animation other than the two parts with links (below), which control the location of the moving blob and the shape of the white beam of light respectively. These two parts are described separately.<br />
<br />
The three top-level layers are as follows:<br />
<br />
<blockquote><br />
<br />
==== top-level layer 1: moving blob ====<br />
<br />
An {{l|Group|group}} of three layers. Its origin is {{l|Connect|connected}} to the {{l|Export|exported}} {{l|ValueNode}} "{{l|Tracking Curves#Moving Point|moving point}}". The three {{l|Layers|layers}} are:<br />
* direction of movement - The fuzzy white beam of light. This is a simple spline with a feather of 0.3 units to make it fuzzy. Its vertices are connected to the {{l|ValueNode}} called "{{l|Tracking Curves#Beam of Light|beam of light}}".<br />
* inner circle - The smaller yellow circle. Not animated at all.<br />
* outer circle - The larger red circle. Not animated at all.<br />
<br />
Note the technique here. I could have animated both of the two circles and the beam all separately, but it is much simpler to group them into a single Group layer and animate the position of that instead.<br />
<br />
==== top-level layer 2: line ====<br />
<br />
The moving curve which the object follows. It has {{l|Waypoints|waypoints}} at 0s, 16s, and 32s to make the line move. I {{l|Export|exported}} four of its animated {{l|ValueNode|ValueNodes}} so that I could use them later to define the curved segment that the blob should follow.<br />
<br />
The exported four {{l|ValueNode|ValueNodes}} are:<br />
* vertex1 - The position of the beginning of the curve<br />
* vertex2 - The position of the end of the curve<br />
* tangent1 - The tangent at the beginning of the curve<br />
* tangent2 - The tangent at the end of the curve<br />
<br />
The moving curve is an {{l|Outline Layer}}, created using the {{l|Spline Tool}}. It only has 2 vertices. Note that the {{l|Spline Tool}} creates layers which have lists of {{l|SplinePoints}} to define the shape of the layer, and that {{l|SplinePoints}} contain more than just vertices and tangents. {{l|SplinePoints}} also have parameters like split tangents', and {{Literal|width}}, which aren't relevant when creating a Segment, so I only exported the four {{l|ValueNode|ValueNodes}} that I needed to create the Segment.<br />
<br />
==== top-level layer 3: black background ====<br />
<br />
A solid black background. Not animated at all.<br />
<br />
</blockquote><br />
<br />
=== Moving Point ===<br />
<br />
The "moving point" {{l|ValueNode}} represents the point on the moving spline where the circles are currently centered. It is an exported ValueNode of type "{{l|Convert#Segment Vertex|Segment Vertex}}". It has 2 components which determine the vertex that is used as its value:<br />
* segment - this uses the ValueNode called "{{l|Tracking Curves#Spline|spline}}"<br />
* amount - this uses the ValueNode called "{{l|Tracking Curves#Spline Parameter|spline parameter}}"<br />
<br />
=== Beam of Light ===<br />
<br />
The "beam of light" ValueNode is a two-point spline, with vertices as follows:<br />
* Vertex001 - This is the vertex at the center of the circle. It doesn't need to move, since the circles don't move. What moves is the "moving blob" layer, the {{l|Group|group}} layer which contains this line and the two circles. So this vertex has a constant position of (0,0)<br />
* Vertex002 - This is the other end of the fuzzy white beam. It was a width of 5 units to make the beam diverge. Its position is connected to the ValueNode called "{{l|Tracking Curves#Scaled Tangent|scaled tangent}}".<br />
<br />
=== Scaled Tangent ===<br />
<br />
The "scaled tangent" ValueNode is the offset vector from the center of the circles to the wide end of the beam of light.<br />
<br />
This offset needs to be a vector in a direction parallel to the tangent to the moving curve at the current point. This was achieved using the Scale convert type, with 2 sub parameters:<br />
* Link - This is the vector to scale. It is a vector representing the tangent to the moving curve at the current position of the circles, and so I called it "tangent". This is arrived at using the {{l|Convert#Segment Tangent|Segment Tangent}} conversion type, which has two sub-parameters:<br />
** Segment - this re-uses the ValueNode called "{{l|Tracking Curves#Spline|spline}}"<br />
** Amount - this re-uses the ValueNode called "{{l|Tracking Curves#Spline Parameter|spline parameter}}"<br />
* Scalar - This is the amount to scale it by. Spline curves have tangents which point from the start vertex towards the end vertex, along the curve. I want my beam of light to point in the direction of travel, which is sometimes towards the start of the curve and sometimes towards the end. To do this I needed to multiply the "tangent" ValueNode above by a number which would be negative when traveling towards the start of the curve. It just so happens that sin(angle+90) has exactly that property, and also has the benefit of making the beam get longer as the movement speeds up. So I called this ValueNode "(sin(angle+90))" and defined it as a "Sine" convert type, defined as value=Amplitude*sin(Angle):<br />
** Angle - This needs to be "Angle+90", so it's defined as a subtraction (Synfig has a 'subtract' convert type, but no add). value = LHS-RHS:<br />
*** LHS - The left hand side of the subtraction - this is connected to "{{l|Tracking Curves#Linearly Changing Angle|linearly changing angle}}"<br />
*** RHS - The right hand side of the subtraction. It's a constant -90.<br />
** Amplitude - This is a constant 0.4, which simply scales the length of the beam of light down to keep it mostly on the screen.<br />
<br />
=== Spline ===<br />
<br />
The "spline" ValueNode is a segment representing the curve to follow. It connects to the vertex1, vertex2, tangent1, and tangent2 ValueNodes, as exported from the '{{l|Tracking Curves#top-level layer 2: line|line}}' layer above.<br />
<br />
=== Spline Parameter ===<br />
<br />
The "Spline parameter" ValueNode is number ranging from 0 to 1, which indicates how far along the segment to go. 0 means "use vertex1" and 1 means "use vertex2".<br />
<br />
I want the point to travel along the curve [http://en.wikipedia.org/wiki/Sinusoidal sinusoidally], meaning it will travel fastest in the middle and slow to a momentary stop at either end. This makes the movement look smoother than using a linear movement.<br />
<br />
The sin() function returns a number between -1 and 1, and I want a value between 0 and 1, so I halve the sin() value, giving -0.5 to 0.5, then add 0.5 to it, giving 0 to 1.<br />
<br />
Consequently, this 'spline parameter' value is the result of a subtraction, LHS-RHS:<br />
* LHS - The left hand side of the subtraction. I called this ValueNode "((sin(angle))/2). This will range from -0.5 to 0.5, and is the result of the '{{l|Convert#Sine|sine}}' convert type, sin(Angle)*Amplitude:<br />
** Angle - This is connected to "{{l|Tracking Curves#Linearly Changing Angle|linearly changing angle}}"<br />
** Amplitude - This is used to scale the value. Since I want sin(Angle)/2, the value is a constant 0.5.<br />
* RHS - The right hand side of the subtraction. I wanted to add 0.5 to sin(angle)/2, but synfig only offers subtraction, so I subtracted -0.5 instead, which is the same. Thus, RHS is a constant Real ValueNode, with value -0.5<br />
<br />
=== Linearly Changing Angle ===<br />
<br />
The "linearly changing angle" ValueNode is the constantly changing angle that drives the whole animation. Whenever the angle increases by 360 degrees, the output of sin(Angle) does one complete cycle from 0 -> 1 -> 0 -> -1 -> 0. The angle changes linearly, using the Linear convert type, which has 2 parameters:<br />
* Rate - How many degrees per second to increase. In the animation this is set to a constant value of 45 degrees per second. This means that one complete cycle (from the center to the right end, to the left end, and back to the center) will take 360/45 = 8 seconds to complete. This gives us four complete cycles in the 32 second animation.<br />
* Offset - The value at the beginning of the animation (time = 0). Changing this to 90 for example will make the blob start at the right-hand end of the line. while changing it to 180 will make the blob start in the middle, but facing (and traveling) left.<br />
<br />
== Screen Shot ==<br />
<br />
This screen shot shows all the exported ValueNodes in the top right. Note that a few of them aren't necessary, such as the {{Literal|yellow}}, {{Literal|red}}, and {{Literal|width}} {{l|ValueNodes}}. Well, actually none of them are necessary - it's possible to do the whole animation without exporting anything at all. It would lead to a small amount of duplication, since both the position of the blob and the direction of the light beam are driven by the same angle. But mainly exporting is a way of naming the ValueNodes, which acts as a kind of documentation.<br />
<br />
In the {{l|Parameters_Panel|Parameters}} panel in the bottom left you can see some of the sub-parameters of the '{{l|Tracking Curves#Moving Point|moving point}}' ValueNode.<br />
<br />
<gallery caption="Track Curve screenshots" widths="500px" heights="600px" perrow="2"><br />
File:Track-curve-tutorial-screenshot1.png|{{l|Canvas}} window and {{l|Parameters_Panel|Parameters}} panel.<br />
File:Track-curve-tutorial-screenshot2.png|{{l|Library_Panel|Libray}} and {{l|Layers_Panel|Layers}} panels.<br />
</gallery></div>Ciaran