I want to contribute to this project! First: Onion Skinning changes?

Compilation and Development
1

Hey. I have some programming skills, though I’d have to get back into C++/QT development. I’ve already cloned the git and poked around some and I think I can contribute to the project.

What I REALLY want to do right now is to improve onion skinning so that the user can choose how many previous and next frames are displayed. This is a really important feature for me, as an animator.

At first I thought there was no way to display any more than the previous frame and the next frame, but apparently there is code to allow to show the next and previous 3 frames, and in fact under Preferences > Tools > Onion Skin it is possible to set the opacity for the next/previous 3 frames. However setting the opacity is broken, it never changes from 50%, 0% and 0%.

I’m going to try and fiddle around with this interface and allow the user to choose how many frames should be displayed, and a min/max opacity that would be gradated between for each displayed frame. I hope this sounds like a good idea to everyone. Eventually it would be nice to place changing the number of frames onion skinned as part of the timeline as it is in Flash, since it’s a nice interface, but it’d be easier for everyone if I make as few interface changes as possible right now, I imagine…

Also what I’d really love is a proper bug and task tracker on this website! But I can’t seem to find one! So I guess posting here is the next best thing.

I hope I’m not getting ahead of myself here, but this seems like a great project that I want to contribute to, as sort of an ex-animator who wants to get back into it on the Linux desktop.

2

Yeah, this is a good idea. But in my opinion, we must first fix the program first. (I know I shouldn’t say “we” but whatever. :P) Make the program becomes as stable as its previous version. 0.5 right now is just less stable than 0.4. So we better stop adding features for now. This might sound like bashing other program but… I don’t want Pencil to be as broken as Synfig. The biggest problem that Synfig is facing is how glitchy and laggy it is. And it seems like the developer has to do it all over again to fix glitches and speed up the program before adding features.

I’m not disagreeing with you or something. It’s just that I feel like it’s a bad idea to add some features for now. We have to find bugs and fix them. We have to find a solution to speed up the program. Then after that, we’ll add some features. (Yeah, “we”. Sorry. I just can’t make sentences without using the word “we”. :P)

Also, in another thread, people want to replace the Pencil’s brush engine to MyPaint’s brush engine. This is not a bug fix but this is also not adding more features. This is just replacing something with something better. It’s a good idea to do it but I just feel like we should fix the program first. (Yeah, I’m a type of guy who thinks about fixing first before adding stuff… I want to help you guys but not right now. I’m busy with RHG stuff in stickpage)

3

About bug/feature tracker thingie, I forgot that github has its own, derp. Not used to contributing to projects like this…

And AdamMZ, basically, I am coming into this from a user’s perspective. I want to take this application and fix it up so that it is usable for me, so I can start animating things. I know there are probably some other broken things – and I am slowly running into them as I use this program more (I only started using it yesterday!). For example, I just found out that when I delete a key, the other keys don’t move back a frame to replace it, and I don’t have any way to move them back. That’s really broken and kinda crazy, and for me to actually produce work with this program, that’s another thing that has to be fixed.

My point is I want to start actually animating using this application. But it’s not at the state where I can start doing that yet. If something prevents me from being able to do so, I want to fix it. And for onion skinning, this is honestly something that prevents me from being able to animate and I want to fix it. Being only able to see one frame ahead and behind me literally breaks this application for me! I just cannot see myself producing anything useful with that limitation. In that way, I consider it a fix, rather than an additional feature.

Additionally, looking through the code, I honestly believe that making this change is going to make the application more elegant, more simple, and less buggy than otherwise. This is because support for displaying three onion frames before and after is hard-coded, but broken. So in a very literal way I will be fixing a bug. At the very least, it’s not exactly adding a new feature, it seems more like a parallel line of what is already implemented, than something in any practical sense that is new.

Lastly, I’ll make the change and submit a merge request but if the developers of this application decide they do not want to incorporate my change because they want to focus on fixing other things than dealing with interface changes, then I understand that. I’d find it a little sad but that’s their choice.

Thanks for your feedback. I hope you understand where I am coming at.

4

Okay, well, I’ve made the changes. I’m really knew to committing to github projects. I committed the changes to my own local branch and then did a pull request. Is that all I have to do?

5

Okay. Pardon my newbiness when it comes to github. I realized I had to make a github fork and then clone that.

Here’s my fork: https://github.com/thorjelly/pencil

I sent the pull request in as well.

6
I’ve already cloned the git and poked around some and I think I can contribute to the project.
That would be awesome !
What I REALLY want to do right now is to improve onion skinning
That is what I personnaly would like to be improved too :) Here is the suggestion I made months ago, if you search for ideas...
Also what I’d really love is a proper bug and task tracker on this website!
You've got a forum for bugs on this website, and a more efficient bug report tool on Github; which should be considered as the main one.
For example, I just found out that when I delete a key, the other keys don’t move back a frame to replace it, and I don’t have any way to move them back.
I'm not sure the default behaviour should be that the other keys move back. (should be discussed ?). Anyway, there is a way to move frames in the timeline, as written in the documentation :
To test and improve your animation you can change the timing of keys. Click to select one key in the timeline and drag it where you want. To select several keys, use the hold the SHIFT key. Often you will want to extend the time between two keys, which implies moving all the subsequent keys. To do that, hold the ALT key and click the second key; this will automatically select all the subsequent keys.
As you are not the first user to ask for this, maybe we should find a way to make this more clear.
I sent the pull request in as well.
Great ! Now we have to wait for @chchwy response :)

Thanks @thorjelly !

7

Re: deleting keyframes
Removing a KEY should never result in other frames shifting their position. There’s a big difference between removing a FRAME and removing a KEYframe. Shifting the positions of frames breaks the timing of an animation, and should be done only when intentionally changing the pace of a particular part of the animation is needed…that’s when removing FRAMES is done. Removing KEYFRAMES should only delete the key but leave the frame in place.

8
I’m not sure the default behaviour should be that the other keys move back. (should be discussed ?). Anyway, there is a way to move frames in the timeline, as written in the documentation :

To test and improve your animation you can change the timing of keys. Click to select one key in the timeline and drag it where you want. To select several keys, use the hold the SHIFT key. Often you will want to extend the time between two keys, which implies moving all the subsequent keys. To do that, hold the ALT key and click the second key; this will automatically select all the subsequent keys.

As you are not the first user to ask for this, maybe we should find a way to make this more clear.

Well, this functionality appears to be broken. Clicking on individual frames does absolutely nothing. There doesn’t seem to be any way to manipulate the timeline frames in the current build. There seems to already be a bug report for this problem: [BUG] The TIMELINE doesn’t allow moving frames · Issue #280 · pencil2d/pencil · GitHub

That is what I personnaly would like to be improved too :) Here is the suggestion I made months ago, if you search for ideas…
Yeah I saw this on the github tracker, here: https://github.com/pencil2d/pencil/issues/17

I mentioned this issue in the pull request too. And yeah, sorry for not noticing the tracker on github at first, I’m a newb when it comes to contributing to github projects. This is the first OS project I’ve contributed to. I’d love to implement this interface as well, the one that was mocked up, or something similar, soon.

Re: deleting keyframes Removing a KEY should never result in other frames shifting their position. There’s a big difference between removing a FRAME and removing a KEYframe. Shifting the positions of frames breaks the timing of an animation, and should be done only when intentionally changing the pace of a particular part of the animation is needed…that’s when removing FRAMES is done. Removing KEYFRAMES should only delete the key but leave the frame in place.
This is true. But right now there seems to be no way to delete frames, as opposed to keyframes, in the current builds. Honestly I never used 0.54 official release, so maybe I don't know how it's -supposed- to work. This is because my distro doesn't have this program in its repositories, so I've just been building it from git. I should try 0.54... because it was very purplexing to me that you couldn't manipulate frames in the timeline at all.

I actually think I know why a lot of this functionality is broken. But I’ll post that in another topic.