some easy (code) work to do?

Hello.
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)?

or sourceforge.net/tracker/?func=d … tid=757416: is this request confirmed? It already looks a bit more difficult, but could be ok.

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 :slight_smile:
Berteh.

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.

Welcome to the coding section berth!

Since the best SVG import is coming from the SVG2SIF Inkscape plugin from Nikita Kitaev, the SVG import module would be eventually removed.

You can take a look to the wish list on the wiki too and on the forums at the feature request too. There are some “easy changes” that can be made.

Please propose here other alternatives and I’ll guide you about the difficulty if needed.

Cheers!
-G

thanks for the proposal. A quick scan resulted in me spotting the following.
You got any priority/preference?
and then hint/instruction/pointer?

thanks.
B.

easy
Fix typos
Suggestion: rename “Center” parameter of Zoom Layer to the “Origin”. Will improve the workflow. --Zelgadis - wiki.synfig.org/wiki/Dev:Wish_li … ste_Canvas

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

medium difficulty
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

Align objects at a common border (as in Inkscape)
wiki.synfig.org/wiki/Dev:Wish_li … n_function & forum

D3. Short cut keys should appear in pop-ups and menus

export an animation to a spritesheet

tough but seemingly very useful
Sound Layer
very good improvement if the sound system were implemented into synfig. --Genete
wiki.synfig.org/wiki/Dev:Sound_Layer

shortcut redesign
Shortcuts thread (full redesing)
Shortcuts + Improved Sketch + Forums maintainence (additional shortcuts needed for blines)
Zoom in/out shortcuts (zoom < > & mouse)

smart rendering
(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
[2] 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

P2P render farm & networkability
wiki.synfig.org/wiki/Dev:Wish_li … orkability

  • 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

vector export (libming? svg? flash? sml? eps? HTML5)
[3] Synfig could export to svg animations with SVG+SMIL, which would make possible to view an animation directly in the browser without any previous rendering.
-> swf / fla: suggested Python’s SwfTools, but isn’t this “only” encapsulating raster?
wiki.synfig.org/wiki/Dev:Wish_list#Flash_export
wiki.synfig.org/wiki/Dev:Wish_li … animations
animated svg or swf output support (mostly flash and svg)

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!

-G

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

SYNFIG_LAYER_SET_NAME(Zoom,"scale"); … 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:

  SYNFIG_LAYER_SET_LOCAL_NAME(Zoom,N_("_Scale"));

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.

Thanks for your help.
B.
typos-studio.diff.txt (2.22 KB)
typos-core.diff.txt (1.43 KB)

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:

else if(layer=="zoom") return Gtk::StockID("synfig-layer_transform_zoom");
to

else if(layer=="zoom" || layer =="scale") return Gtk::StockID("synfig-layer_transform_zoom");

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:
loadcanvas.cpp:2139
layer.cpp:149 and 89
module.h:100
layer_std/main.cpp:86

To fix this you need to add one more alias for the old zoom layer:

[code] LAYER(Zoom) LAYER_ALIAS(Zoom,“Zoom”)

  •   LAYER_ALIAS(Zoom, "zoom")[/code]
    

But it is needed that you understand what are you doing.
-G

Thanks Genete for these info.

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?

Thanks again.
B.

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.
-G

Hello,

Here’s the final patch for fixing the various misleading labels mentioned in
wiki.synfig.org/wiki/Dev:Wish_li … ste_Canvas
sourceforge.net/tracker/?func=de … tid=757416
Misleading labels

  • proposed new icon (scale tool recoloured to match transform layer style).

I didn’t change the internal name of zoom layer, as a closer look to the current sources made me realise the other menus are not sorted anyway and that was the only reason for wanting to change it.

B.
layer_transform_zoom_icon.sif (189 KB)
typos-diff.txt (4.26 KB)

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:

  1. iconcontroller.cpp
  2. images/makefile.am (in various places)
  3. other place I don’t remember now :mrgreen:

-G

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)

The solution for the gradient sliders is on its forums. That new code task is good as next step.

The patch for the rename of the icon file looks good to me. I’ll try to apply when I have a little more time.
Thanks for all the patches!
-G

Thanks for all the patches berteh!
You are really working hard! :slight_smile:

you’re welcome.
B.

Seems all of us forget there is a “zoom” in parameters list, which refers to Scale. Inline Canvas at lest. :slight_smile: