Most probably. Maybe that should be an option. In fact for more-less complex scenes you probably use preview, not scrub…
@Genete:
Editing the library file is is very common situation. We very often use layout like shown on the attached screenshot.
The only requirement - user needs to watch that both files should be on the same frame. Otherwise the image in the child window will be buggy. That’s also the reason why I claim for synced timelines.
I mean for animating, not previewing. I’m constantly dragging timeline back and forth when animating. I think Synfig needs to go towards faster canvas interaction/update/workflow. Anything introducing a slowdown is a step backwards in my opinion.
Your other points seems reasonable.
I’m sorry but I have to disagree on this. For me a library is something that you use several times on different client files and by its own definition, the library when modified, is modified for all the client files. If you are using an imported file and need to edit it to fit the situation on the importer client document, then it is not fully a library, it is a copy of the library and so like that it has the same effect that if you copy the library contents inside the client file and you get an independent copy of the library on that file. Even that copied content can have valuenodes (or other imported files) that belongs to the libraries, and if they are changed, will be changed everywhere they are used.
So if the imported file needs to be modified to match the client file needs, then better than import the file it is to just copy the content inside the client file, leaving the valuenodes and imported files untouch when they belong to real libraries data.
Hard link timelines is not a good idea IMHO. It could be better to make a soft link of timelines. Say that the timeline of the currently focused window is the master one and the other windows’s timeline are updated only when focused. If you need to see the child canvas updated on the parent canvas then just go to the parent canvas and scrcub the timeline. Then if for some reason you need to edit the child canvas, switch to it and (focus it) and it will sync in time with its last parent canvas focused. Those soft links should be able to be edited in some kind of preferences panel (maybe the canvas browser).
-G
now, I learned, for synfig studio multi-document handling, we have to consider two things at least:
1, all the opened documents are independing,
2, some of them are imported into the others.
the first one is more simpler to implement/design
There is a third view:
The document has exported canvases that might be wanted to see in its own independent window.
-G
Add a playback widget as Rylleman mentioned.
To get the idea, please take a look at the image linked at the first post 
<jaw dropping!
Awesome work!!
Can tabs be torn off? Keeping a preview window on a separate monitor as example.
Can tabs and windows still be arranged any way we like? Grouping different tabs as we please.
Tear off tabs/canvas windows are reasonable as you mentioned, but We need to look into more details how to handle canvas depended statuses, zoom level, animate mode, for examples. Does these widgets should appear each canvas window? For torn-off panels, should be more easier to implement, current preview window, for example, is already torn-off 
(2012.3.26) Updated the mockup by adding:
First off. Just like to say thank you and good work to the development team.
I can’t wait for the single window option to come into play like they did with GIMP. Even before the recent versions of GIMP you could use python scripts like GIMPbox (that was in Linux) to keep things together in a window.
I hate myself when I instinctively click on Synfig in the taskbar when switching from my broswer and I have to click several times (when I could have just minimised my browser). I’ve just downloaded VirtuaWin and now I’ll try running Synfig in its own virtual desktop (I’ve assigned “Alt + 2” as my hotkey) to develop a new habit 
The Redesign looks great. I have one thing to think about regarding the Layers Panel and the single UI layout.
As we know in Synfig, the layers panel can grow quite large. We should always keep in mind ways to make it easier to scroll through dozens of layers. Or options to give the Layers Panel a lot of screen space.
Since Synfig is getting a single window mode perhaps this topic should be in the announcements for now?
Considering we’re either still brainstorming or already began coding the single-window mode, I thought I’d post this (since it was just now uploaded):
youtube.com/watch?v=UWacQrEcMHk
Andrew Price proposed some interesting changes to Blender’s user interface, which I posted about here: (Blender ) UI Redesign: Principles
And that video I linked to just now is the third part of the proposal. XD I hope it sparks some inspiration!
I tried the development snapshot at work recently to check out the single-window interface, and something bugged me:
Why have TWO timeline scrobblers? I mean, despite the progress we’ve been making (and I love what you guys are doing here), there’s still so much… stuff… that’s taking up the screen estate. One of those being the timeline scrobbler in the Canvas window. Since we’ll be using the timeline scrobbler in the Parameters box, why would we need another one in the canvas window? I’d suggest remove it, although, you could instead just give people the option to “hide” it with an option in the View menu.
Another thing: The Gnome Shell window-decorations. Would Synfig be adapting to it in Gnome environments, but still staying as it’s always been in others? This one isn’t necessary, I’m just generally curious.
It would nice to be able to go from this:
To this:
In a single key stroke (or mouse click).
Maybe even throw in an intermediate state with screen split half&half between parameters and canvas (ie. old style).
The reason is that when working with shapes on Canvas one doesn’t care much about parameters, and when working with parameters only one doesn’t care about Canvas. Only occasionally there’s need for both at the same time.
The Canvas panel could be shrunk vertically as the mockup above. Or maybe the there could be a hidden panel “behind” the Canvas which can be revealed/hidden with a single key press. This panel would work the same as any other panels (so it’s layout would be customizable).
EDIT: Actually the idea of shrinking/expanding panels could be applied to all panels. For example there could be a button to shrink a panel vertically to it’s smallest possible size (similar to feature on desktop environments, called “shade window” in KDE, “roll window up” in XFCE). Then the other panels would automatically take up the freed space. Also would need a way to restore panels to their previous size.
Maybe it would be possible to have a “maximize” feature, which would shrink every other panel to give the maximized panel as much space as possible. Then the “restore” button would revert layout back to the original.
Each panel would need to provide a way to shrink it to a minimal size (like “iconify this dock” on Inkscape). Right now panels refuse to shrink beyond some (not so small) minimum.
Yes, It is necessary to improve/polish the features implemented recently. Wish we can have “a perk to polish existed feature/s priorities for development” in the coming months.
I am experiencing a little bit about the Sing-Window Mode UI polishing, the attached screenshot is a snapshot of the current situation. But I am not a professional coder, so that I can not promise if it will be done as planed.
Sounds nice.
I am doing menu re-arrangement at the moment, the File->Panels menu is now not a standalone top-level menu, which be renamed to Window. Besides “Reset to Original Panels Layout” (renamed to “Default”), I would like to introduce some more predefined Workspace sets:
[code]Workspace
Any comments/suggestions for predefined workspace layouts would be fully appreciated!
And sure, it is necessary to have ability to save customized layouts (workspace).
Nice idea, would you please file a feature request at issue tracker
