Synfig Meeting
Saturday, July 7, 2007 by pabsPosted in Announcements
Page moved to the wiki: Meetings/2007-07
It is time for another Synfig Meeting. It has been scheduled for July 28th at 6PM UTC. As per last time, we'll use the IRC channel and possibly gobby (or the wiki) for meeting minutes and other notes. There is a rough agenda, please add any suggestions to the wiki page (or comment below and we will add them).
See you all then and happy drawing!
Entries (ATOM/RSS)
Thursday, July 12, 2007
Not sure if you have already implemented this. But do you think it would be any good, to have the synfig save file consisting of a single compressed g-zip file?
Within this save file is a multiple txt files in multiple folders that describes difference aspects of animation, as well as different folders for different scene. (Done to semi-xml standard?)
In another folder exist a library consisting of individual elements of the reused objects used, in synfig saved as svg files?
The reason for this setup is so that the work of artist and animators, are better future proofed against changing computer structure and standards.
It would be a shame if really good animation that is produced by this program, fall in to the trap of technical obsolescent. (like some of Disney old vector animation, the old computers that can still read it may break down in the future.)
There are many benefits to changing the structure of this superb program early on, to maintain competitive advantage(Within the open source world) than waiting later on.
Talk about my idea and tell me by my email if it sounds good.
at
akimbomidget+gmail+com
Wednesday, July 18, 2007
Akimbo gzip gets good compression but if you were considering having multiple project files you would be better off with zip/jar as your container as it allows variable encryption and direct access to individual files without needing to unpack the whole file. depends on what your requirements are really but either way using a library like libgsf might make the implementation easier and allow for better reuse in other importers and exporters besides the native format (and presumably as SVG support gradually improves SVGZ support would be wanted so all kinds of compressed file formats are a predictable request).
Thursday, July 19, 2007
Good point
Well we can slash that idea down to its basic component(&And add your idea to the equation), what i want the save to be made of is this.
A container file, with multiple compression option. All to Open Source Standard.
+No Container whatsoever (Just a network of folder and files)(Best for special long term archival purpose, bad for storage) +Non compressed raw synfig file (fastest access) (But bad for long term archival purpose, but is automatically selected for slow PCs) +Individually components compressed (Like in zip, Jar) (Standard Option) +Archival (GZip, etc) (For general archival purpose)
Within this storage option, contains a folder who's tree may/should look like this.
-+Scene1 –SceneDetails.Xml –+Svgs –+Image
-+Scene2
-+Scene...
-+Global Elements –Elements.xml –+Svgs –+Script <-- For automation of complex scripted animation (Like the cracking of glass in Xmen 2, they didn't animate that by hand.) –+Images
Of course this idea is still pretty rough, but on the overall the principle is still good.
Any better? More appealing? What do you think Alan?
Saturday, July 21, 2007
Akimbo my intention was only really to encourage developers to reuse existing libraries such as libgsf, used by projects such as abiword and gnumeric for handling file streams. I would not be attempting to implement anything so I would be careful to only suggest rather than push developers to do thing in any particular way.
In terms of the file format I'd be inclined to go for ZIP/JAR or something along those lines because believe it or not it fulfills pretty much all your requirements* and I'm very familiar with this debate from when OpenOffice XML was first developed (and later becoming OpenDocument). Following an existing approach also makes it easier to reuse or repurpose existing tools or scripts.
In any case this could be a very long and uninteresting dicussion and those who write the code will make most of the decisions, and simply producing a gzipped version of the existing file format might be more expedient.
[* The default implementation of OpenDocument doesn't show half of what the file format potentially allows, and many people misunderstand it to mean the things they want are not possible simply because they are not the default output of programs like OpenOffice. Take as just one example KOffice which include the option to save OpenDocument as files and folders. A program could equally produce a single highly compressed Zip file, as opposed to the default which leaves the manifest and certain other information with no compression for faster access.]
Thursday, August 9, 2007
How did the meeting go? Was it constructive?
Thursday, August 9, 2007
Wai-Tung: Nope, not really, not enough people showed up, there was some discussion on the mailing list though:
http://thread.gmane.org/gmane.comp.video.synfig.devel/347
Tuesday, August 21, 2007
There's a vicious cycle going on with this program. For it to become more widely used it needs to be in the hands of creatives. Creatives on the mac is in no short supply. The same, however, cannot be said for programmers. I'm not saying that only mac users will use apps to create, nor that no mac user can program. But if you see the example of Blender3d, it started to build a lot of momentum when they were releasing it on all platforms simultaneously. How can we get synfig on mac osx? Practically. Without reliance on x11. X11 is a temporary solution - it's so slow it makes inkscape virtually unusable on my old system. And open-source programs sure do appeal to the cash strapped such as myself. So here's the solution:- ALL programmers should immediately stop what they are doing and concentrate on an osx AQUA version. I think that will please everyone. hehe. But seriously, I don't see much use on youtube examples [other than Voria] that is not some test of tweening or colour cycling. Now I've read the original email and it seems to me that the creation of synfig was not firstly for these type of animations [tween/bones - Flash\Moho style], but to assist in in-betweening of ‘hand drawn’ [including mouse drawn] frames. I think people should bear this in mind, and those that are able to use this intriguing application should really be steering their work to test synfig as a capable tool for those purposes. Mathematically driven animation should come secondary.
Just trying to get some activity going on, don't be too mad at me.
Tuesday, August 21, 2007
macuser: buy me a fast Mac and I'll consider trying to get synfig working on MacOS. I think it already works there, you just have to be able to use a compiler.
Otherwise, perhaps you could contact madsen and ask him about progress on his mac packages.
If you want to get rid of X11 on MacOS, please support these people (with code, money or whatever):
http://developer.imendio.com/projects/gtk-macosx
Once it is usable, synfigstudio can be compiled with it and uploaded to sourceforge.
The youtube videos you mention are by people who want to understand how synfig works so that they can use it for real animations. Documentation is important, and these animations are documentation.
Anyways, synfig needs more developers first, people to handle the infrastructure, then people to document it and then artists and then users. We need more people involved. On IRC, the wiki, mailing lists, the bug tracker, SVN. Doing things helps the project, comments are great, but generally don't get anything done.
Saturday, September 1, 2007
Two words: wxWidgets!
It has native support on all platforms, which means WinAPI on Windows, Cocoa on MacOS, and X11 or GTK on Linux. I myself have managed to get a Cairo window running in a test wx app, and it runs just fine. That and the dockable window library wxAUI is incredibly fantastic, and comes with wx 2.8.4.
Sunday, September 2, 2007
Will you be rewriting synfigstudio in wxWidgets ion?
Sunday, September 9, 2007
You developers have to change your way of thinking if you want this project to be successful. Blender is a success because it's developers are also the artists that use it. You guys are already The GIMP, with developers that use it, and everyone else hates it. You've even copied the horrible UI. Another reason Blender is successful is that it's only done in one language (c++) and graphics are done in openGL. compared to that this program is much slower in speed, and porting.
And the multi window interface needs another mention, as it is the most hated by people who have used the commercial products. Far too much time is wasted on shuffling through windows, and suggesting not to have any other applications open is out of the question.
Sunday, September 9, 2007
Shadow, Synfig was developed as an in-house animation tool and very much used by the artists that worked at that studio. Unfortunately there are no ‘You developers’ now. There are a few people that are exploring the Synfig code and figuring out what it can and should be able to do. Right now the main focus is on fixing the crashes that stop more people from even playing with it (that and trying to find a Mac OS maintainer). Maybe one day down the line Synfig will have a host of developers with time and energy to reimplement the interface. Until then, if you know artists and developers that can use and improve Synfig, please encourage them to get involved.
Tuesday, September 11, 2007
If you want developers i recommend removing the archaic things like Fortran configuration scripts. What I think would help the most to attract developers is moving the code to a Mono framework (time consuming, but probably worth it).
I'll keep using Synfig as an artist though. Which raises the question why layers in synfig are different from photoshop, gimp, inkscape, etc..
Wednesday, September 12, 2007
As far as I know there has never been any connection between FORTRAN and Synfig. I'm not sure what you're getting at there.
I don't know much about Mono. Isn't it an attempt to keep up with a proprietary Microsoft technology?
Synfig layers are quite different things than photoshop, gimp, inkscape, etc. layers. Each layer is a single object or transformation, with a fixed set of parameters which can be animated. It might have been a good idea to come up with some name other than ‘layers’ for them to avoid the confusion.
Wednesday, September 12, 2007
Look in the wiki page for setting up mingw on windows for the mention of Fortran. If it's required to build it has to be in there somewhere.
Yes, Mono is a clone of .NET, but there are a lot of .NET developers out there since it's easier to get started with. Since Mono is available for every major OS it should mean not having to take time to port the program anymore. I'm not a programmer, so I'm not sure about a lot of the details. (There are only these options for GUI though http://www.mono-project.com/Gui_Toolkits)
Tuesday, September 18, 2007
"Will you be rewriting synfigstudio in wxWidgets ion?"
I wish I was that good of a programmer! I just think its a good idea to move to an object oriented framework that does a better job at cross platform. The Mono .NET thing would accomplish the same thing too (but I haven't used it so I wouldn't know if it's good or not).
Tuesday, September 18, 2007
Re-writing synfig in .NET would probably 1) take a bloody long time (there is heaps of code) 2) make it slower than it already is 3) expose us to the conseqences of any Microsoft patent offensive against Mono (ie - synfig might have to be rewritten in another language). Best keep it in a vendor-agnostic language anyways.
Tuesday, September 25, 2007
Yeah, rewriting Synfig in any language would be a heap of work. In my personal opinion (having looked a bit at the code while trying to do the Mac OS X build (X11, Intel only)) it would probably be better to simply do a code cleanup, since it looks quite messy to me, but I'm not a programmer (at least not a C/C++ one) and I've never worked on anything big, so maybe I'm just looking at it wrong.
As for cross-platform toolkits (wx etc.), they are not really that great, since they are NOT native, though they may look so, they definitely don't behave so. A lot of the Cocoa-behavior is lost, while some GTK-features are also not supported, all because they can only allow elements that are implementable on all “supported” platforms. Not really viable for a highly GUI-based app like Synfig. For small things, like network tools and such it's great, but think about it, there's a reason that Gimp and Pidgin/Gaim uses GTK instead of wxWidgets.
If Synfig were to be ported to OS X for real (without X11), then an approach like that of NeoOffice (Cocoa version of OpenOffice) or SeaShore (Cocoa version of Gimp) is needed - that is, a real Cocoa port, which I'm not able to deliver, as I now squat about coding Cocoa apps.
I will, however, try my best to fix the Pango-issue, that is currently holding back the OS X binary (which does require X11 and is Intel-only), but I'm low on spare time, so it might take a while yet, since trial and error involves some testers to be sure it'll run on a vanilla OS X install. (I have the testers, they just don't have a whole lot of time either.)
Everyone complaining has GOT to remember that this is something people work on in their spare time out of sheer interest, so try to be constructive (which most of you appear to do) and you might just get a constructive response.