Pencil2D Roadmap Discussion & Resources

Ideas
1

Hey everyone, so as some of us discussed last year, we need to get going a roadmap for Pencil2D, not only to know where the program is heading but also to keep track of existing features , and which features are worth adding (we could also submit this to vote).

This would be to ease the work between veteran and new developers that arrive. Github helps with tracking who is doing what, but we all don’t know where were heading, it’s been basically a dance between fixing previous bugs and spurts of coding for most.

But do we really know what we want Pencil2D to be? Some of our user wrote their thoughts here:

http://www.pencil2d.org/forums/topic/pencil-users-developers-raise-your-voice/

And I’m currently (although sluggishly) compiling their answers in a little document for everyone to read later on. EDIT: Your thoughts and contributions are highly appreciated to make this rough document work for us in the long run!

The raw directives I can think for this developer roadmap are:

  1. There should never be a question of what task is being currently performed.
    2) It should always be known who’s working on a given task.
  2. There should be a clear way to view which tasks are free / pending
    4) Tasks should be organized by difficulty, priority and utility:

Difficulty: Veteran programmers should take on the most (apparently) difficult tasks. Novice programmers should be able to take the least difficult tasks.

Priority: Critical bugs Should be solved first if they affect>>>

  1. Software Stability (i.e segmentaion faults, memory leaking)
  2. Functionality & Purpose (i.e The program is not working to fulfill it's primary role; the tools are not working like they're supposed to)
Utility: The last way of categorizing. It's for those problems that are found but can be classified as "If ain't broken, don't fix it" workarounds. For example, say if the eyedropper is working properly, but you want to make it to work by pressing ALT while having the rbush tool selected, but doing so will totally wreck the eyedroper code. Don't do it. Not yet, anyway.

If you can think of more stuff, please comment so we can find a proper way to get this working.

QUESTIONS FOR DEVELOPERS:

First of all I would ask you to propose what kind of system we can use to map out Pencil2D progress, that is all the features that are already present in Pencil2D.

Second, How can we add to that map a “future” presentation of the “coming-up” features

Third, how we can streamline feature requests from developers and users. what formatting should we use, and what kind of criteria we would require to approve these new features.

Fourth, should we categorize which features are essential for Pencil2D “core” and which can be thought out as plugins / extensions? If this turns out to be true, how do you propose we do it.

Fifth, After understanding what we want form Pencil2D, we NEED coding standards, solutions and whatnot. And please, comment the code! A “coding guide to Pencil2D” wouldn’t be a bad idea either. I’m not talking about teaching c++ with Qt. But rather mapping out what each library and method does. This would become our developer documentation.

Sixth, …to be continued.

Anyway, please propose your thoughts on this. I’m not a software engineer at all, but I’ve coded in the past.

We must understand that the success of any kind of collaborative effort is to get organized, and it’s getting late for Pencil2D to get on track.

The main idea is that no matter who ends up developing this application, when things have been said and done, they have enough material to continue and not to deviate from the main purpose Pencil2D will serve for animators all over the world.

2

I think the main thing is a system where developers not tripping over each breaking each others stuff. We need to get a master branch that’s near as bug free as we can get it, Then slowly bring in new features, so the users can break them in ways developers never imagined the software would be used.

3

One of the projects that I did some contribution on seemed to break down over undo/redo functions. (I don’t know if this will be an issue for pencil) I was browsing over the code, at I got the impression that the undo works by restoring a frame? I haven’t dissected the code yet, it looks like I need to poke around backupelement and editor. I can figure it out, but I was wondering if there was anything like a design guideline, vision statement…etc… on undo/redo on how this all works.

(The way this came up was that I was doing a little googling research for design patterns for dealing with disabling/enabling menu items/buttons) paste on keystroke and click events through a common routine to cut down on the bugs by disabling them when they shouldn’t be active.)

4

@jonasthomas That’s exactly the problem we’re facing right now. we DON’T have such kind of guidelines. Whatever the original author of Pencil had in mind died with him (so to speak) There is kind of a “vision pf pencil” but it’s more of a design philosophy take on what the program should strive for.

http://www.pencil2d.org/2010/06/the-vision-for-pencil-by-pascal-naidon/

I think though that we need hard facts and documented behaviourson how the code actually works, plus where we should be heading afterwards…It’s weird that no one has commented this yet :confused:

I was actually going to ask all of the devs if there could be a way we can begin to document your findings upon browsing the code (and to comment the code too!). No-one seemed to think that was important at the time of it’s inception, but I think it’s a critical step on this new project, particularly because we don’t know who will leave or who will arrive to code on this.

5

You are right @morr.

I don’t have much experience on community based development but I guess that the right way of doing this kind of development exist.

First of all, I think that the decision on the roadmap only belongs to the original authors of that specific Pencil2D branch. I mean Matt in here and maybe a couple of others who started this branch. It is their project, their boat and they decide where they want it to go. If their vision, is the same as Pascal Naidon, then we have our roadmap and we should make anyone who wants to help in the development aware of it.

Apart from the original authors, anyone can propose their ideas. The forum and github are good places for that. Some people can freely implement their own features on their own branch but only the original authors can decide to have them merged in Pencil or not.

I am not too kind about voting for features because it always adds some work to the process and the end result is not always consistent. There is time for democracy but artwork and design work should be directed by a small deciding entity. Imagine an orchestra were every musician had to vote for each music note. How long would that take to write a symphony and what would be the result? :slight_smile:

Of course features that are required by many or great features developed independently are usually accepted by the authors but this always comes naturally.

I guess this is how Blender works. Their is a deciding entity and many external developers free to develop what they want. At the end, Blender chooses what to merge and not to merge.

So first of all, we should define the main deciding team and the role of each of them. The ideal would be to have :

  • A director, to get the decision every time the team is divided on a specific subject.
  • A project manager, to handle/clean up the github issues mess, discuss with the developers and assign the tasks.
  • A development leader to define the right technology and development good practice.
 
6

@feeef I completely understand what you’re saying. Of course it’s easier to have always a small “core” team that decides where the program is going. But my problem right now is that we don’t have that small core team yet.

Indeed Blender Foundation has a core team (which is the blender foundation itself) and they propose stuff on their code.blender.org many people are welcome to argue back, but once they feel thinks are ok, they will go ahead to implement it.

I’m not well versed in politics either :stuck_out_tongue: , but since this is an open-source program and there has not been a true roadmap establishment since the beginning of it’s inception, I think it’s time for us, the community around the project, to implement it. Of course, this is not something to be “imposed” over anyone, not the project “rescuers” nor the community itself.

All of this must be subject to civil discussion, otherwise it defeats the purpose of being a program made by people, for people. Voting was meant as a way to get developers on track, but only within that small core team. --I don’t think thousands of votes to define a feature, even if we had a well established, trusted community of end-users & developers, would work either.

So far things have worked out, but I have a gut feeling that we don’t really know where we are going, except for trying to make a working animation app with our understandign of animation as a guideline. Many potential devs have asked in the past “where is the roadmap?, what are we supposed to d?o” but they left because there wasn’t a guide for them to use.

Also, we need some basic coding standards, a pencil2D coding guide so people new to the project can KNOW what classes exist, what they do and all that stuff that would take just too much time to understand just by revieweing the code, plus a lot of functional comments in the code (which is proper practice) that last time I reviewed the code, they seemed to be missing.

Again I’m not a programmer, I’ve just had coding experience in the past but I don’t know how to build software, I have no clue about design patterns, but I’m trying to learn and study to help out somehow.

Either way I TOTALY AGREE that we should define the core team right now, but for that we need everyone who has been fairly involved to comment here and output their thoughts. Hopefully most people have some spare time to continue assisting Pencil2D!

7

I’m working on Pencil2D for personal interests. I will continue working on this software, because it is a software that I want to use. I will resolve bugs that are in my way, and I will add features that I want to use. This is how opensource works in my mind.

8

@derek_saif It’s fantastic that you have a personal motivation to develop Pencil. Certainly we all are here because we need the program one way or the other for our personal and professional purposes. So thank you for helping out.

However don’t you think it would be better if we all could collaborate on getting there by helping each other? I mean it is also in the spirit of open source development.

What are those features you want to use, as opposed to the features everyone needs? are they the same? are they different? That’s what I think we all need to negotiate with the Roadmap.

Certainly we who are here and now want the same on a general level: A lightweight, easy-to-use, powerful and stable animation program to create “the illusion of life” through hand-drawn animation for production.

We don’t exactly want a “Toon Boom” or a “Flash” or a “TVPaint”, because those applications already exist, and somehow we can’t either afford them or they are lacking something for our own purposes.

I’m pretty sure though, that we want something that allows us to draw, ink, paint, video edit, camera pan/zoom maybe have some primitive sound editing, and if I stretch that idea to even have some primitive node compositing through OpenFX for simple yet needed effects (I’m thinking really far with this) and maybe if life is good to us, allow pencil to organize your own production with a system of scene or shot planning for Pencil files that would help to increase efficiency within a team of animators. I always advice not to work an animation production on a single file on any program, it’s best to work by scenes, or even by cuts.

Anyway, hopefully we can all work out something to allow everyone involved to fully cooperate towards having pencil ready for webcast & broadcast production in the future.

Thank you again for your time and efforts have a great weekend.

9

For me, I have personal interest in QT and C++, I use C# at work. In addition my daughter has expressed interest in animation. I just want to get the stuff that’s broke fixed to get something my kid can use without getting frustrated when it breaks.
My main concern is over developers tripping over each other breaking each others stuff especially when someone is just feeling like itching a scratch without regard for others. (I don’t see this this happening in this project at this time)

At this point, I feel like pencil2d as a project like a patient thats in rehab. We need to make her healthy. There are enough things wrong in separate areas that as long as we mention who is working in the issue list, it will work out imho

I think the time for voting is when we have a healthy patient and we’re we want to do major plastic surgery on her to improve her. I think it will be at least a 1/2 year before that becomes a problem.

From my perspective, it seem like there have been significant improvements in the usability of the software in the last month, and I hope this continues.

10

So… the “right way” to solve this

is with something called Test Driven Development. We're supposed to have a testing suite that tests every function of the application. You're supposed to run the testing suite before merging any code in to master.

I’m not particularly sure how we would do this with a graphics application. Maybe we would simulate mouse clicks save the file, then compare the resulting file to a known correct result.

There’s also something called the QT Testing Framework it looks like

The “wrong way” to solve this is to continue developing and making changes and hoping that nothing else breaks and when it does hope someone catches it and files a bug report. I’m going to continue in this way, because I don’t want to spend my time setting up TDD; however, if someone else sets it up, I’m willing to write tests for any code I contribute.

===

After conferring with some folks in #linux on freenode.org I think a roadmap is a good idea. We should update Home · pencil2d/pencil Wiki · GitHub

after discussing the roadmap

I don’t think the roadmap will effect what we’re doing in the short term, but it will effect what we do in the long term.

11

@derek_saif I didn’t even know we HAD a roadmap page on github facepalm I agree on the testing, huge props to your friends at ##linux. There should be a way to make a rough roadmap document so we can later upload it on the github then. There’s also the Pascal Naidon “Vision” for pencil which helps with this as well:

http://www.pencil2d.org/2010/06/the-vision-for-pencil-by-pascal-naidon/

But I think just having “one” document would be best.

I consider myself O.K at “beta-testing” so to speak. I like to document how to reproduce the bugs trying to observe and understand the behaviours behind them. I found 6 bugs on the latest nightly build that was uploaded after the first 10 minutes. I was thinking of doing short videos to show the steps and explain the bugs, because they are quite entertaining and a bit difficult to catch if someone is not paying attention.

If there’s something I can do to help , like creating a guide for testers or bug reports let me know. I could even do a testing template spreadsheet if you guys need.

12

Can’t argue with anything you stated (including not wanting to setup a TDD either)

I’m thinking we keeping new functionality in new separate branches and have users test them heavily before a final merge is probably the most pragmatic thing to do other than TDD testing

I was looking at the road-map, in relation to the copy-paste issues. I need to ponder on this a bit.

An issue for me is that users are not leaving enough of a trail of bread crumbs to following consistently in bug reports. We should make it easy for them to give the info required.

One thing the freecad project does that I think is pretty cool is to put the boilerplate info needed for a bug report in the about button where this is a button that the user can copy into his/her clipboard and into the bug report. It seems this would be worth doing… Any thoughts? (Other than go for it?)

13

Jose I thought your guideline was a bit long winded, but I’m beginning to appreciate it.
On you section here you say:

Priority: Critical bugs Should be solved first if they affect>>>

  1. Software Stability (i.e memory leaking)
My suggestion is to edit to add this.(i.e segmentation faults, memory leaking)

At this time, I think stability of the master branch should be the primary goal. We don’t have that at moment. I don’t want to discourage the itchy scratch developers, but from my perspective new features means new unforeseen bugs.
Maybe we should say something like:

New enhancements that would require a revision to the github roadmap and are not related to stability of the application, will not be merged into main github repository until the main branch is stable.

New enhancements that are within the road map but are not directly related to master stabilization should be brought into the main github repository as a branch for testing and evaluation. Primary developers, super-users will test the enhancement within the branch, and its deemed stable and add value to the application merged it into the master.

 

14

Jose had posted a video of the bugs he found in the latest daily build.

I really liked it and had few suggestions for improvement…
Any thoughts on my thoughts?
http://www.pencil2d.org/forums/topic/bug-video-bug-report-nightly-build-jan-15-2016/#post-27871

15

@jonasthomas Indeed, I agree on having stability as a top priority, to me critical bugs are just the opposite of that. Basically every bug that makes the app crash or initiate the dreaded “no response” in windows / mac.

To be honest I’m a bit over my head here, I have some knowledge of how software works but whatever suggestion you guys have i’ll add it so we can begin to shape this document.

We can of course simplify it later to make punctual notations on how to organize most the priorities so devs can focus on realizing the general area that needs work and getting the hands-on approach on tasks and bug fixing that meet such criteria.

16

The main thing that called my attention among all the topics in the comments was to realized that most (if not all) of the past Pencil2D Builds had bring new bugs and some has “destroy” the work of another developer. So I really think that the way you are discussion it right now is the proper thing to do. This way you/pencil2D may improve a lot more, and not as in the past: just one step forward, two steps back.
I think it will be a good idea if you all consider to ask for some help on the Blender3D community since they are very well aware of the importance of that thing that you called Roadmap, and they are doing a great job by now.

About the video of @morr, I agree with @jonasthomas when he mentioned that too much information all at once in one video is not a good path. Resuming the information (bug reports) may help the way developers work with each other.

Another point, not sure if it has been already mentioned here, is to give a person (developer or not) the “responsibility” for checking duplicated reports. I myself found it too frustrating trying to help @Matt and developers with a clean set number of bug reports while on the other hand new bug reports were added without paying too much attention to the already extended number of open bugs on the bug list.
That doesn’t mean that I am against any new bug report, but at least just in case please check ALL (yes ALL :slight_smile: ) the other reports in order to see if there are similarities or are duplicated. This way the list of bug will be clean and the number of them will be a lot less, and as a direct result developers will feel confident about there own work seeing a correct list with a correct number of open and close bugs

For reporting Bugs, @morr already suggested long ago a simple Guide for new and old users to report bugs (not sure where it is right now)

One thing that I also find to be of a great priority is this webpage of Pencil2D. I always found the WordPress to be too limited, and so there is no much to do in order to change the site to be much more pro-active related to users. For instance, there is a big Bug here in which every post edited by a user will be posted as original…

All for now

17

Thanks a lot for your feedback and help @alexandervrs !

You could help with UX improvements as well. Even mock-ups proposals.

Pencil is still a simple application but I know that some features are not very well implemented in term of UX.

None of us, developers, have good experience in UI design so your skills are very welcome indeed! :slight_smile:

Thanks for your feedback anyway!

18

One of the best thing about Pencil2D is the fact that I can animate as soon as I open the software. Where as other alternatives have been quite daunting. There is so much on the screen, and learning the software itself takes time. And learning animation while doing that is pain for me. Hence I resorted back to Pencil2D, and believe me I have tested almost all available 2d animation softwares. They may have their advantages, but the simplicity of pencil2d is just amazing.

Here is my take on how the progression for the software should be like, Stability? Yes, this is core for any software that exists. I have yet to face any crashes, but the only reason would be that I might not be extending the limits of the software :smiley:

Anyways, once the stability issues are fixed, the focus should be on smoothing the workflow of the timeline, followed by some advanced vector editing(3-point Bezier curves). With this, atleast we will have a solid foundation to animate with clean lines.

Following this, the next tools to be worked on are the ones related to the coloring part. The fill tool should be optimized for this, like understanding the ignore small gaps, etc. The brush tool would be used to fill in the small edges missed by the fill tool. I have no experience on this, yet, so I will leave it at that.

Next, and this is way-way-way in the future, an NLE w/ either Layer/Node based Compositing. But this is asking for too much, and as such, should be left to softwares that are dedicated to it(eg:Natron/Kdenlive).

So yea… I would be quite happy with having an easy and simple animator that helps me with animating the lines and some decent coloring that’s good enough to have the ‘cel’ look.

I gave some time to read the visions of Pascal and well, its a long way to go, I will be happy to help in anyway possible, except with the programming part :stuck_out_tongue:

 

 

 

19

Thank you very much for your feedback @sumit_makwana!

Having some compositing features is something I also wish very much. Pencil2D could integrate some interesting layer based compositing features with not so much effort and it is something I seriously plan to work on in the future, when the application will be in a stable state.

Here is how I see it :

  • I would first implement compositing/blending mode to the layers (a small dropdown menu on each layer). This should be pretty straight forward as, thanks to Matt's refactoring, we already have all the structure to do that in the code.
  • This will make it possible to easily create masks. If a mask is made on vector layer it can easily be transformed for rotoscoping by copying and adjusting it through the different frames.
  • I also would like to see a way of grouping layers (folders) with the ability to add a blending mode to a folder.
  • Then, I would add the possibility to keyframe any layer or group's size, position and opacity. Not only for the camera.
At this point we would have a strong compositing base without too much effort and without affecting the UI.
20

@feeef For the compositing features, I hope we can work directly with core pclx(pencil) files. I don’t want to work with image sequences all together until the final stage for video editing. I don’t know how to explain this actually.

What I am trying to say is that, if there could possibly a way, to import the pencil animation files directly into a layer as an independent clip of it self. So that rather than working on composition in the animation file itself, we could make a separate file for the compositing process, leaving the animation file unharmed. I hope I’m making sense?

Also, in regards to some of the visions by pascal regarding other uses for pencil(note taking, video editing, etc.). Could we just create separate .exe for their respective purposes? Like once we install Pencil2D, multiple executable files will be create eg: Pencil2D Animate.exe(this will be our current version for animation), Pencil2D Video.exe(this will be optimized for video editing), Pencil2D Composite.exe(this will be our compositor), Pencil2D Note(the note taking software), Pencil2D Story.exe(for making detailed storyboards). It will be like a Pencil2D Suite or something :slight_smile:

The problem then would arise for the file format interchangeability. Each of those should know how to read the file saved by the other ones. Or maybe a universal file format? Then there would some sort of chain of how the data would be read. Its getting a bit complicated here and my mind getting numb. So I have no clue how this would even be possible. lol :smiley:

In short, I’m simply suggesting that I don’t want pencil to be similar to how blender has different modes to be selected from a drop down menu. A Pencil2D suite sounds interesting to me.