i’ll tell you mi toughs, perhaps this behavior might be also related to GNOME, i remember using XFCE and Anime Studio Pro and also Synfig, as i told you before, windows were actually placed as i left them last session every time i opened the programs, this specially with Animt Studio which acts a little rebel in GNOME, all the windows are disordered or misplaced, or maybe i should say not in the position i left them (i have version 5.6, =C cannot afford a copy of 6 release for Linux which has a better layout, hope we can have something like that in the future), gettign back to the post, the thing is that in XCFE i hadn’t to much problems setting the window size and position as i have in GNOME, have you alternatively tried with another Desktop interface than GNOME?, if the problems lies in the Window Manager or in GNome core, you’ll be able to know.
I can reproduce the problem with sleep(1) just before the load_settings() call in the app.cpp file.
-G
The sleep call idea from nikitakit has allowed me to try to understand what’s happening during Synfig Studio initialization. I’ve noticed that the dock dialogs are shown before the settings are loaded (the dialogs are shown with its default size). I assume that if the dock dialog is visible, the windows manager can act over it so I think that it is a bad idea to show the dialogs before load the settings.
I’ve committed a change in my genete_master branch to try to fix this. The dialgos are not shown until the application want them to be shown. So loading the settings doesn’t imply re-show the dialogs. I’ve created a member for the dock manager that shows all the dialogs and it is called just before re-show the toolbox, once the settings are loaded. The effect is that the dock dialogs are shown with its current size and position.
I hope this solve the problem.
Please checkout the branch and test it. I would like to have feed back from people that have noticed this problem before.
Thanks
-G
Great job genete - no more problems for me!
Genete:
I have tested fix with all “bad cases” mentioned here and can’t reproduce the problem anymore! Awesome!
Let’s wait for Pixelgeek’s feedback…
Thanks nikitakit and zelgadis for the testing!
I’ll apply to master and wait for pixelgeek feedback.
I’ll release a second candidate I think. 
-G
I’ll try and build & test it tonight - I had a busy weekend.
Pixelgeek, the initial layout is going to be fixed. I’m working on that. What we need to know is if the mangling problem happens or not now. In linux I trigger it by resetting the initial window configuration and then close and open synfigstudio several times. One of the times (randomly) it used to mangle the dock sizes and ruin all the window layout.
-G
I’m not seeing that problem, but then again , I’m using GTK 2.16. Need me to upgrade?
Theoretically it is 2.18+ when the problem started. Are you going back to 2.16 or I’m wrong if I remember that you used 2.18 in the release of 0.62.00 for windows?
It seems that the problem with 2.18+ is solved with the patch but if you’re using 2.16 in the next release it won’t be a problem with the windows version.
Besides that, shouldn’t we be consistent on windows releases so we don’t get back to old gtkmm versions on newest releases? Some day we would need to use some of the new gtkmm 2.18+ library fucntions so the earlier we upgrade and make the problems arise, the earlier are them solved. 
-G
I’ve been using 2.16 with Synfig for windows since August of 2009. Looks like 2.18 came out in December, and 2.20 in early April of this year, but I haven’t downloaded them yet. Since we’re bundling the binaries with Synfig now, I don’t see any point in upgrading right now. Unless there are any benefits for doing so? New features we’re using?
Chris
I think that we can continue using older ones in windows binaries. If in the future we need with no replacement any of the features of the new versions then you should upgrade. Linux problem is that libraries are going faster and we need to update code to “fix introduced bugs”
-G
LOL. Greatest joke! Genete, you are good at marketing! 
Hi there.
I’ve committed changes to allow dual splash screen and also I’ve fixed the reset initial windows configuration to fit the primary monitor size.
I hadn’t enough time to release the second candidate but you can test the changes in the master branch.
I’ve noticed that the feature that I introduced to change the cursors when using the Transform tool, ruins the other tools cursors as well as it seems that the keyboard wrapping is done in any tool state.
I think that there is a solution by forcing the tool status to keep the cursor all the time. It is a kind of hacking because I don’t know why the keyboard is wrapped in any tool state but it might solve the cursor problem for all the tools.
Anyone has other idea?
-G
My son has a lenovo laptop with Windows7. I’ve installed in it the “all in one Synfig package”, but it doen’t work well: it doesn’t draw the Blines or figures an it doesn’t fill
the regions. I can try in it this release, but I need you to tell me how to do.
Better wait for a binary release from pixelgeek.
-G
Ok, things are very close to the end now.
Tasks done:
- Write the Press Release. It still unpublished and has been nicely reviewed by pixelgeek, nikitakit and berteh.
- Tag the git commit after a little mistake
. Now it is stable. - Create the 0.62.01 tarballs and upload them to sf
- Create the binaries and upload them to tuxfamily.
. Now it is stable.I wonder if we (pixelgeek) should reconsider to organize the uploading folders at sourceforge. I believed that it was a good idea to provide a tarball with the three etl, synfig and synfigstudio tarballs to make easier to download a single package for the distro developers. (they are here). But the windows binaries have been uploaded there too. I guess that it will be less confusing to the user to separate windows binaries from general propose code tarballs. I’ve created a windows-binaries folder for that (it is empty at the moment). What do you think pixelgeek? Can you move the older windows binaries to there and upload your windows binary in the new folder. If so, I will delete the deb and rpm from that ETL-Synfig-SynfigStudio folder and only upload there the package of the source code.
For linux versions I prefer to provide binaries (universal rpm, deb and targz) from tuxfamily, and leave sf for source and windows binaries.
It is pending:
- Publish the Press Release
- Update the download links
- Send all the short press releases to the magazines etc. etc.
Please let me do the step of publish the Press Release after we agreed where the files will go on sf.
Cheers.
For Windows users - sourceforge.net/projects/synfig … e/download
And after reading Genete’s post, sourceforge.net/projects/synfig … e/download also works
I’m not too worried about where they are as long as they show up, and can be downloaded easily.
Enjoy, Chris
I think it’s better to store linux binaries onsf.net for 2 reasons:
- Keep everything in the same place is logical.
- We have unlimited space on sf.net. Considering that there will be lot of more releases… Let’s save tuxfamily’s resources for other purposes
So my suggestion:
- store release sources and binaries on sf.net
- store temporal builds (development snapshots) on tuxfamily. But maybe use sf.net for that too? They can be removed anytime…
I have a proposal for folder structure at sf.net:
- “ETL” - for all sources of ETL (without subfolders for each version - this is redundant)
- “synfig” - for all sources of synfig (without subfolders for each version - this is redundant)
- “synfigstudio” - for all sources of synfigstudio (without subfolders for each version - this is redundant)
- “binaries” - for Linux and Windows all-in-one packages
** “binaries/linux” - linux packages
** “binaries/windows” - windows installers
** “binaries/mac” - mac packages (someday)
Also, I think there’s no reason to make all-in-one source packages. That’s a wasting of web and time resources and having too much alternatives for downloading the same thing confuses users.
Note to all: please don’t forget to replace “https” to “http” in urls.