Hey!
there are some branches that should be incorporated into synfig master branch and maybe need some confirmation from other users.
Those are the issues:
pixelgeek_windows_single threaded
Although main testing should be done under windows platform I with that people with other linux distributions test that branch and confirm that it still working without any additional issue.
I’ve tested it under Ubuntu 9.04 and works fine.
nikitakit_svg
Nikitakit, can you rebase your branch to include the current master branch status? That would allow me make tests wihtout need to change the command to remove the line of the libltdl in configure.ac for ubuntu 9.04 and later. That issue is solved in the current master branch but it is not inlcuded in your development branch. Also I would want to know if you still developing it or if it is ready to be merged to master.
nikitakit_ducks
Please beware on commit *.po files when you’re not doing a translation update. That can cause troubles. As you can see you had some conflicts when merging other branches with the modififed *.po files.
This branch includes two modifications:
a) Smooth bline
b) New Tool Transform.
Although it is good that those modifications are commited I wish that both were kept in their own branches to allow easier debugging and testing.
a) Smooth bline. Can you explain how to test the changes made?
b) New Tool:
It works pretty good. I just miss that the CTRL+SHIFT comintation restrict the rotation to a predefined angle amount (maybe in the tool options panel)
It has a small bug. Tangent, Radius, width and angle ducks cannot be translated individually or in groups. The scale and rotate operations works but not the translation.
Also, checking the Constrain checkbox, doesn’t affect the translation movement. It should.
Excellent work anyway!!
I think the line “#define SINGLE_THREADED” should be deleted from the code. Since it doesn’t scope properly (the file isn’t included everywhere the definition is needed), the flag has to be declared in the compiler options. There’s no need to be redundant. If the declaration isn’t done somewhere in the configure script or makefile and the branch is compiled on Windows, I believe it will fail to build. Please tell me if I’m misunderstanding something.
Can you teach me how to rebase remote branches? My current git skills only allow me to rebase local ones. If rebase isn’t possible, I’ll merge master into this branch.
EDIT: After today’s commits, I’d say it’s ready for merging. I might come back to working on it, but that probably won’t happen for a while.
My lack of git organization skills is showing here:
po files are there by accident. If I figure out how to do interactive rebase remotely, I might scrap them. However, I have already merged in master a few commits back and settled all the merge conflicts in favor of the master branch.
Smooth BLine is a misnomer, what the branch actually does is replace some hardcoded link indices with names. If I actually implement smooth blines, then I’ll push a new branch onto the server.
EDIT: Actually, I accidentally included one extra commit from nikitakit_smoothblines than I intended, so there are some changes to core/blinepoint.cpp/h. I need to figure out how I can fix that.
The tangent/radius/etc bug, now fixed, is an absolute embarrassment caused by a single line of code.
The SHIFT key is mapped to restrain movement elsewhere in the code (I finally tracked down that bit of code). As such, its restraint of movement is actually totally independent of the “Constrain” checkbox. (This also causes jerkyness in constrained scale tool). I would like to talk to you about keyboard shortcut implementations before proceeding to fix the key combinations.
The rotate and scale tools aren’t really necessary now. (If the artists feel otherwise, please tell me.) So, I erased all the files so that we don’t have dead code/files hanging around. The code has all been copied into normal state, and the icons will always exist in git history: recovering them on demand will be no problem.
The branch contains a variety of miscellaneous changes (bline indexes, blinecalcvertex reverse manip, duck drag code). They are all interconnected, so it was easier for me to make the changes in one branch. In fact, all the code would require manual merge if it were in separate branches.
The blinepoint and po modifications, on the other hand, are totally my fault. I’d like to retroactively edit commit history to fix them. If you know how to either a) interactive rebase remote branches or b) delete the origin/nikitakit_ducks branch, please tell me. (If you delete the remote branch, I’ll retroactively edit the history on my own computer, and then push the modified version)
Hi nikitakit,
regarding to the branches and code mixing it is not a problem at all. I’ve reviewed a patch from current master to your latest commit of the kinitakit_ducks branch and all the traces of the po and blinepoint modifications are disappeared, except a white space in a line on blinepoint.cpp and .h. I’ll restore them
I think it is not worth to make a “clean” commit although it is possible. I can create a new branch from current master and do cherry picks from the commits I want one by one, avoiding the commits that doesn’t belong to the new tool addition. Any way the commits are self explanatory so they can be there.
My idea of code modifications is that all commits of big changes (i.e. smooth bline) were contained in the same branch when possible and not some of them in one branch and others in other branches and so. Keeping all the modifications together allows to make a later debug easier.
Regarding to rotate and scale tools presence I would like to listen other users opinion. They are indeed in the git repository and yes, carry on the files is not necessarily really.
Anyway, I’ll merge the branch now and if some one else wants to restore the deprecated tools we can always restore them.
I’ve noticed that after move the code related to dragging of “Link to BLine” ducks out of DuckDrag_Translate and into Duck, causes that the feed back received, when you for example drag a star that has its position and angle linked to a bline, disappeared. In the previous version, when you drag a origin that has an angle duck linked to bline too, you get a instant feed back of the angle rotation when dragging the vertex duck. Now that feedback has gone.
That’s not a big deal but it was cool to have that feedback.
-G
I’ve just commited a fix for the angle feedback issue. (It was because I only included width and tangent ducks in the check for which to update)
At the same time, I stumbled across a variety of link-to-bline related issues. These have to do with studio’s design: there’s no easy solution.
The live feedback for tangents/widths/angles used to be a large code chunk in duckdrag_normal. (Yes, live feedback only applied to the normal tool). I moved most of it into duck so that there is less code repetition. The relevant function is Duck::update(), called in most of the duck draggers’ duck_drag methods. If you can come up with a better way to implement it, please tell me. (I’m leaning towards combining the “for” loops in the duck draggers and Duck::update() into a new function as part of Duckmatic)
I’m done with all of my tool-related changes. You can go ahead and merge nikitakit_ducks in. Any future changes to the branch won’t have to do with the transform tool; I might use the branch to refactor some more duck code (That’s why I originally named the branch nikitakit_ducks)
