I think the current code organization it’s a bit bad. As I’m the new guy, I can’t be doing changes without asking , so I’m going to tell you what I’ve changed in my branch to go on with it or revert to the old state to continue working on it.
In the Core:
Target_scanline and Target_tiles shares a lot of code, but Target_scanline seemed to be repeating a lot of it. So I’ve made Target_scanline look more alike Target_tile (added a new function, render_frame_(), which stores the rendering code) and the file has shrunk a lot, which I think it’s good.
I’ve also moved the layers, valuenodes and targets in its own directories. So, the current structure it’s src/synfig, src/synfig/layers, src/synfig/targets and src/synfig/valuenodes.
In the Studio:
I’ve done the same moving with cellrenderers, dialogs, docks, renderers, states and widgets
I think that it’s easier to work this way, at least to a newcomer to the code. You can see the changes in my branch on git.
Do anyone have any objection? Or have any recommendation or something? I’m all ears .
Current bones branch development is based on svn version that have the old structure. As you changed the main structure of the folders (and consequently their includes) it should be done on bones branch one both merge.
I’m worried about a big merge of both branches (although they don’t share much files really) because that change should imply a adaptation commit before merge. I don’t know whether bone branch will be finished before of after opengl one. Only wanted to mention that the folder change should consider offside effects.
Do we know how many source files have changes on both branches? And do we know which files?
Maybe it is a good idea to do a test merge of both branches right now? To see how difficult a merge would be? That way we can see whether preventative action is required.
I’ve locally merged the opengl branch with the bones branch and logically there were conflicts. Bur most of them come from the modified paths of the include directives.
Only two files:
duck_renderer.cpp
workarea.cpp
were affected in the body of the code. But it seems to be easy to fix. Both codes doesn’t affect same members, just share the same space of the file so they can live together properly.
Of course configure.ac and Makefile.am had conflicts but obviously they will always have and are easy to solve.
Anyway, I’ve done another big change. Time class was in conflict with X Time class, so I had to rename it to Synfig_Time. Also, renamed the files time.h and string.h to synfig_time.h and synfig_string.h.
Any objections?
We’ll have to do another test merge, but I don’t think it’s going to be a big deal, maybe just like the previous test.
Are you sure you committed those changes for all files? I have various files in the synfig-studio src directory that still refer to synfig::Time instead of synfig::Synfig_Time… Also the Makefile in the po directory of synfig-core doesn’t seem to be updated to reflect your file renaming. I also have trouble automatically compiling the code in the libltdl. Do you have any ideas?
Sorry Gerco. I haven’t modified studio files yet, because with the current core, studio it’s unnusable. And .po files are unchanged, too, because every time I do a change, all .po files change and I don’t want to commit them until finished.
Your problems with the libltdl maybe are caused because you already have a libltdl in your system, and you have to remove it from compilation. In configure.ac, search for the line “AC_CONFIG_SUBDIRS(libltdl)” and comment or remove it. That’s unchanged from previous versions.
, so I’m going to tell you what I’ve changed in my branch to go on with it or revert to the old state to continue working on it.
