I may be able to contribute some coding effort in the next few weeks, no promise though.
I don’t know C++ (yet) but was pretty familiar with OO (Java), did some C, and used many other languages (from Prolog to Perl)… so I guess the gap shouldn’t be too big. So: Do you have some easy (pending) things I could start with, that would help while allowing me to get familiar with the Synfig internals?
After a quick look at the bug tracker I spotted sourceforge.net/tracker/?func=d … tid=757416: Is it still a valid request? would you rather see me try to fix it only on the cosmetics (studio labels and language files) or the very heart (core classes, methods and more)?
If you have another preferred easy prey let me know.
I would love to be able to fix my own issues or provide for new hand draw rendering modes, such as a pencil-like look or some of freestyle’s great looks (japanese, chaining, technical… amazing!)… maybe based on the advanced outlines… but those will have to wait
Personally, I think adding a font selection dialog (I believe there is a standard GTK one) would be a huge help. At present you have to type in font names by hand which is inconveinient and error-prone.
I have no opinion on the coding bit other than “Horray!” but I want to comment on the tasks as I started the first one. It’s still valid from my view but I’m not sure how others feel about this change (zoom>scale).
On the second task I just added a comment to the tracker.
Triangle sliders to be always visible - triangle sliders from Colors Dialog and Gradient Dialog were visible whatever color or channel you’re editing. Some times when the color or channel is to bright or light the slider is difficult to distinguish. --Genete wiki.synfig.org/wiki/Dev:Wish_li … ys_visible
Font selection dialog
Duck for Amount value in Zoom layer - (2) It would be nice if Amount value in Zoom layer was controlled by additional duck. --Zelgadis
The Amount parameter works exponentially; each time you add 1 to the Amount, the image is zoomed by a further factor of e (= 2.71828 or so) wiki.synfig.org/wiki/Dev:Wish_li … Zoom_layer
(only frames with diff from last rendering + timestamp on ?visual? modifications)
More specifically, only render frames that need to be changed since the last rendering as defined by something like a last edit (or write to filesystem) timestamp and a dependency tree. …In the short-term, a tool like gmake might be useful for implementing this accross sessions if we add “last changed” timestamps to one or more sections of sifz files
 It would be nice to have option for smart rendering for PNG sequences. The idea is: Synfig dumps XML code of the frame and generates a checksum of XML code. Then it writes the checksum as metadata to png frame when rendered. If the the rendering done second time (on top of existing image sequence), then synfig first compares the generated checksum and checksum in existing file and does rendering of that frame only if checksums mismatch. --Zelgadis wiki.synfig.org/wiki/Dev:Wish_li … trendering wiki.synfig.org/wiki/Dev:Wish_li … _rendering
related: Collect for Publication: (3/4) - (zotz) Menu item, functionality that would collect all files referenced in a sif and place them all in a tgz for sending elsewhere or publishing animations in source form. wiki.synfig.org/wiki/Dev:Wish_li … ublication
To allow you get some satisfaction and behave used on the terminology and structure of the Synfig code I strongly reccomend to start from easy to medium and after time gives you more experience to the diffult areas.
I would pick up the three easy ones and in the order you have presented it. Once you get them working then think on others medium or I can propose others average tasks too. I wouldn’t start one complex directly. I can lead to frustration.
In any case if you feel brave to acomplish any of the complex one, go for it!
draft patches attached.
They require more work to get the icon updated as studio does not associate automatically the icon
synfig-studio/images/layer_transform_scale_icon.png (or sif) to the (former “zoom”) layer by only changing its name
… what do I need to do to get the icon right?
One (more) question for my education:
if, in synfig-core/src/modules/lyr_std/zoom.cpp, if I use the following to get a shortcut in the Layer menu:
then this string _Scale shows (with the underscore) as default layer name in studio. To avoid this I dropped the shortcut. Is there a means to have the shortcut AND the default name with no underscore?
I’ll updated the patches when I figure how to fix the icon issue. Please don’t apply yet.
And I can’t upload patches to related tracker, so I put them here for now.
I see that in the patch you have changed the layer name ( the string used on the sift) files to identify a layer by its type. This has many implications and one of them is the missing icon.
In this case you have to change the corresponding entry on the icon controller.cpp file of this line:
So when the layer is “scale” it uses the correct icon.
I don’t think we need to change the icon name because it is used by the coders but in case you need to do it you have to touch other files too.
The other side effect of change the name of the layer type is that this layer is defined in a module and the module registers the layers into the application by a register system. So when one old layer type is found (‘zoom’) the layer type is not found on the layer’s book and seems not registered. It then creates a Layer MIME type and continue loading the file. But that’s not the right thing. It might be necessary to create a layer alias register to allow load old files with the old type ‘zoom’ in it.
This can be found at:
layer.cpp:149 and 89
To fix this you need to add one more alias for the old zoom layer:
[code] LAYER(Zoom) LAYER_ALIAS(Zoom,“Zoom”)
But it is needed that you understand what are you doing.
I thought I needed to change the layer name for it seems to be the string used for menu entry (alphabetical) sorting, but I’d rather not modify this name for the many reasons you provided. Is there a way to have menu entry sorting on another key than the internal name, where does it happen for now?
No need to change the icon name indeed.
Thanks for the info on registry and aliases. Makes the things much more clear, because indeed I need to understand exactly what I’m doing. Are these kind of internal mechanisms explained anywhere so I bother you less with newbie questions?
I can’t answer that right now, because I need to search through the code using ‘git grep’ that I don’t have in this computer. But I can tell you that it is done automatically iterating in the list of registered layers and yes, they seem to be sorted by the type name.
I’m afraid they’re not. The comments on the code might help a bit, specially the header files.
Patch looks fine to me as well as icon. I think that keep the icon file name as zoom instead of scale is not a big deal, since it is just a naming convention. Maybe it could be interesting for you to change the icon name and then change all the consequences that the file name change implies. That would be a good excercise.
Implications of rename layer_transform_zoom_icon.sifz to layer_transform_scale_icon.sifz covers:
If you could provide me with alternative easy ones that need to be done it’d be welcome.
fyi I’ll be looking next at adding a “font family” value type to support some dialog/list with selfcompletion on a font parameter… but only after I fix my current patch for triangles in gradients editor.
meanwhile attached is the change of name for the zoom/scale layer icon, as you suggested. This patch needs to be applied on top of my former one, it ships the new icon file and required code changes.
B. scale-icon-name-change.diff.txt (197 KB)