September 2019 Transcription

September 2019 Developer Meeting

Meeting began at approximately 12:10 GMT Saturday, September 7, 2019

Members in attendance:

• Connor (@scribblemaniac)
• David (@davidlamhauge)
• Jose (@Jose-Moreno) (text-only)
• Oliver (@CandyFace)

Audio Transcript

Connor] Thank you for coming to the second team meeting of the Pencil2D developers. In this meeting we will be discussing primarily what we are going to do for the upcoming v0.6.5 release. There's lots of outstanding PRs and lots of outstanding issues as always and we just need to figure out what we want to do and by when. That's basically the rundown of what this meeting will hopefully be about. I don't think we introductions, do we?

David] No, I don't think so.

Oliver] No I think it's fine.

Connor] Okay good.

[pause]

Connor] Okay then let's start with going over what is already been merged into master. Just a reminder that with the release schedule that we agreed upon in the previous meeting, this next release is going to be a feature release, which means that in addition to all the bug fixes that we do, any new features can be added to it. Yeah.

David] Ye.

Connor] So I've started to go through the list of commits since v0.6.4. I haven't really organized it very well but I'll just kind of run through them. Some of the biggest changes are the peg bar alignment and the refactoring of the selection behavior by David and CandyFace respectively. There's also been a lot of small bug fixes. A couple typos have been fixed. We've added constrained rotation. Jose changed the preferences slightly so that the autosave wouldn't come on so often. I fixed the onion skin rendering. I know that was giving everyone some problems. What else, am I missing something here?

Oliver] Yeah we have some autosave preferences and the grid stuff what David did I believe.

David] Yeah.

Connor] Okay yeah.

Oliver] And also Jose adding or setting the autosave max up to 8000-something. Setting the initial value and also refining the grid's width and height minimum values.

Connor] Right and we just merged that PR about the scrub playback which would-

David] Yeah.

Connor] -which would move the timeline as you're moving the scrubber or playing an animation.

Connor] So I think that's about it for what we've merged so far.

Oliver] Yeah sounds about right.

Connor] As for stuff that's...waiting I guess. We have the new undo/redo implementation by CandyFace, or I guess Oliver I should call you.

David] Mmhmm.

Connor] The feature to copy, move, reverse, and delete multiple frames by David. The x-sheet feature by David. Bringing back the light table or relative layer visibility by CandyFace. The bitmap colouring branch by David. The layer merge feature by David. Changes to the numbered image import by CandyFace. The color history/recent history by chrisju; a new contributor or relatively new.

Oliver] Yeah.

Connor] Ah yes and changing the line color by David. Refactoring the tool logic by CandyFace. Adding presets by me and movie import by me. That's all we've got open right now. Maybe we should just go around for a moment and everyone can just breifly mention what kind of things they're working on right now, if anything.

David] Well I'm not working on something in particular, and I know that some of those features you mentioned that I have implemented are waiting to have the undo/redo thing done, so they have to wait for that. I think. What do you say Oliver?

Oliver] Yeah that's at least what we've discussed previously and I still that that's a good idea, at least for some of it because it modifies a frame quite heavily that could potentially destroy the work. Yeah. For what I'm doing currently: I'm working on the undo/redo branch, trying to fix the last couple of bugs or so.

Connor] Alright and right now I've been just doing some small bugfixes and changes. I'll make a PR for a group of them soon enough. There was one that came up recently in the forums I think it was about the hand tool with tablets, that's fixed now. A couple others. I'm also trying to test the undo/redo branch as much as I can. Once I can find anything wrong with it, I'll start reviewing the code hopefully.

Connor] So I guess what we should discuss next: which of these features that we've listed, and any that you think we still need to do for the next version or that are important to get in there, what should be included in v0.6.5?

David] Well the one enhanced relative layer visibility, I mean that is not dependent on of redo/undo is it?

Connor] I don't think so.

David] I can't really see that.

Oliver] No.

David] And the improved numbered image import as well should be at least merged I think. What else I think is...? Well the presets I would love to see that merged to, but I can't remember if there were any there.

Connor] We were discussing the UI of it a little bit still.

David] Okay, yeah, yes. Yes, I remember that. And then the movie import. I mean it's just like importing a lot of images, but if it the software suddenly gets 70 megabytes bigger, I don't really know why, but I guess it's true we need to say this. And I don't know, can't it be done without that ffprobe? We use ffmpeg for something, can't ffmpeg do it, or is it just slower or why do we need the other one?

Connor] Uh without going too much into the technical details, it's easier to use ffprobe. It's designed to be parsed by computers rather than human readable. I think it could be reworked to use ffmpeg, or we could just get rid of that feature. Basically, that's responsible for determining the progress of a movie [import] which I think is pretty import but if you guys think that's not worth it then that's something we can just remove.

Oliver] Well I mean I think it's a good thing to have easy import of video clips or something because people do that and we tend to give them [workarounds?] right now so I'm definitely not disagreeing to that part. I just think that we should consider the requirements for such feature right now. And it's true that we can probably rework it later and decrease the file size again. And I'm not saying that we can't add this feature simply because it increases the file size. I'm just voicing my opinion on it I guess.

Connor] Yeah that's good.

David] Yeah. Well it makes sense to say we are now doing something that is really [bulging?] our software to a size that it shouldn't have. But I also think that it's a feature that we need. I myself would like to have some reference if I want to do some rotoscoping or something. And I guess that's what we need it for. I don't know what else but well that's for the users to decide what to use it for. But I think it's a good feature and we should have it. Whether it should be now, and we work on it and refine it later or we should merge it later I don't know but yeah. Megabytes don't count as much now as when I had a 40-megabyte computer in the late eighties [laughing]. You know you can't buy anything that's less than 500 GB almost. I mean so I don't think it's that big of a problem for our users.

Oliver] Maybe not. I just know that we have a lot of people from, or Jose has mentioned quite a few times that we do have some people who are from less advanced, technical-wise, countries, I don't know, something. That could be affected by this. Still a lot of countries don't have very good Internet connections so downloading 200 MB is not a problem for me and probably not a problem for a lot of people but it might become a problem for some.

Connor] One option perhaps is that we could exclude it from the legacy builds, or maybe the 32-bit versions, as those are usually older and smaller in hard drive size right?

David] Mhmm, yeah maybe. I'm not into the technicals.

Connor] I guess we're getting a little bit off-topic. I think what I'm hearing is that that might be something we want to include in the next release. You also mentioned the relative visibility and the presets, right?

David] Yeah.

Connor] What else?

David] Yes. The visibility, the improved numbered drawings import and the add preset support. Those three could be merged I think, if they are reviewed of course. They don't depend on the undo/redo as I see it.

Oliver] Yes, I agree.

Connor] I also agree.

David] While the others...

Connor] Beyond those, I think this version should be the version undo/redo branch merged. I know it seems a little bit far off still. We're still finding a lot of bug and things with it, and it's going to take a long time to review probably just cause it is such a big change. But I think you know it's been in the works for a very long time and it's starting to hold up other things which is why I think we should try and focus on merging that perhaps.

Oliver] Yeah, I think that's indeed the good thing exactly because we other things that need the capability of being able to undo/redo in my opinion.

David] Ya.

Oliver] And you could say that it's true that it's a lot of code to review.

David] [laughs]

Oliver] But the good thing is that it doesn't modify the core code that much. It's mostly code in new classes, so the BackupElement and the BackupManager. So hopefully it shouldn't modify anything from the core classes. I mean there could be side effects.

David] Hmm, yeah. And you have no idea how long it will take to get there. I asked you a week ago and I think. But when you have such a big stone in your way you want to when it's been done with. But it could be a month more or what?

Oliver] I mean possibly. I work on it basically every day to get it done.

David] I can see that.

Oliver] I just hopefully implemented ability to undo/redo selecting frames and moving properly now, which was a bit of work. And then yeah so I'm back on track now. I'm trying to fix the remaining bugs and hopefully there's going to be nothing left afterwards.

Connor] Hopefully.

David] Yeah.

Oliver] But I mean it could be a month yeah. It's likely. It's plausible.

David] Yeah I'm just looking at what Jose's writing. He says split tool logic could be merged too. Does that affect the...that has nothing to do with the undo/redo does it? Number 1255, split tool logic for bitmap and vector. I don't know.

Oliver] It does because I have to this save state and [?] backup [?]. That would have to be done again, but for each bitmap and vector tool now. So it would require a bit of refactoring, that one. But as I found that it shouldn't affect it.

David] Oh and then of course it has to be reviewed.

Oliver] Yes and it is quite a lot of code in that one too because I'm basically splitting the tools up, looking much similar in some cases. But I think it's needed because we have all this layer checking that we do in each tool, and I don't think that's very good. It costs sometimes side effects and complicates the code a lot sometimes. And also considering that in the future the vector tools might become a lot more complicated, then it would require almost it's own tools. That's why I did it.

Connor] Yeah I like the changes or the idea of it, but since it is just refactoring it will probably, like you say, have to be redone for the undo/redo, I don't think it should be a priority for the next release. What do you guys think?

Oliver] Yeah I think that's fair.

David] Yeah, I think too.

Oliver] It touches a lot of the core code and if there should be anything. I tried to refactor and not change any behavior but it still happens sometimes. So if that's the case then I'm suddenly having to look into that code to, what would be , I don't know. So yeah I think we should skip it until the undo/redo is in.

David] Good.

David] So we have three of these PR that would be merged and then the undo/redo when it's finished and then we go on with a new release. Is that it?

Connor] Uhh...

Oliver] Uhh...

David] Or did I miss something here?

Oliver] No I think that's right. I think Jose got it wrong or I did. We're agreeing that the undo/redo, that we should wait for it to get in right?

David] Yes. The next release is with the new undo/redo. And then we the add preset, the improved number import, and the enhanced relative visibility.

Connor] And possibly the movie import.

David] Maybe the movie import-

Oliver] Yeah [?] that one too.

David] Maybe other things a well but let's see.

Oliver] I mean basically anything that doesn't require undo/redo could get in.

Connor] And I don't think that will affect the undo/redo. Just to be clear, because you back up the image import right?

Oliver] [?]

Oliver] Yeah.

Connor] So maybe that's it for PRs, but are there any issues that we think are important enough to fix.

Oliver] I mean we did have the milestones right which doesn't look quite as what we...well sorta. We did have a feature request for instantiated frames but I'm not sure that we should have that one in this release. So this ability you know to duplicate a frame, and whenever you make a change on that frame, you will affect all of the frames.

David] Hmm

O} Then we had something about improved select drawing rotation.

Connor] Oh that's done already I think. Isn't it?

Oliver] [?} Yeah okay. Okay yea, Jose hasn't reported back on that one it seems. So it may be done.

Connor] One thing that's kind of related to the workflow restructuring that's kind of... I'll say work in progress but their hasn't been much work on it. We'll need to, or I think we should migrate the nightly releases and the official releases out of [chchwy's] account. Right now all of those things are getting generated when he pulls the code to his fork, which really slowed down, well not slowed down but complicated the previous release. I know he's been quite busy lately it seems so if we want to do a release, we need to do that first.

Oliver] Okay so my pull request changes are affecting the nightly builds.

Connor] Uhh no this is nothing to do with any of the current pull requests it's something that's always happened but it would just be easier if when when we commit changes to master then the continuous integration for the Pencil2D team is the one that uploads the build to the Google Drive. And when we push to the Pencil2D release branch, then it uploads right away to the drive as well. Is that making sense?

Oliver] Yeah okay.

David] Maybe. Not for me but it makes sense for you just-

Oliver] Yeah it makes sense.

Connor] Okay, well take it from me. If I'm going to be the one organizing the release like last time then that's something I want sorted out. Cause that was a big pain last time.

David] Yeah sure fine. Okay.

Oliver] You're welcome to do that.

David] Yeah.

David] Okay.

Connor] Just an idea, this kind of goes into the next point that we wanted to talk about, about the scheduling or ordering for the release. If we all agree, and it sounds like we're agreeing, that the undo/redo PR should come before the others, or before the other ones that are affected by the undo/redo like the layer merge and the copying frames and all that, then we could rebase those branches off of the undo/redo, or merge them or whatever you want to do, so that you could start working on updating those features to include the undo/redo branch before it even get's merged. Does that sound like something you'd want to do?

David] Surely, sure. When I tested the redo/undo on one occasion, three weeks ago or so, I did the same. I made a branch and merged the undo/redo into that branch and I tested it. I think it's a fine way to do it. So get the undo/redo finished and then we merge it into the PR branch, yes? That's what you're thinking is?

Connor] Yes. Well it doesn't even have to be fully finished.

David] Yes yeah.

Connor] As long as there's no major changes to the undo/redo then that would help catch you up right?

David] Yeah. So I take my copy move reverse thing and I merge the undo/redo as it is now.

Connor] Right.

David] And then yes implement it and see if it covers the cases that I work with here, the copying and moving and so on. Yeah. I could do that.

Connor] Jose has a-

Oliver] Yeah [and if they?] don't then we can always collaborate on trying to get some elements in that will work.

David] Yeah.

Connor] Jose has a good point here that x-sheet doesn't really depend on the undo/redo either does it?

Oliver] No.

Connor] Well, okay aside from maybe the lipsync import.

David] Yeah but the x-sheet branch that I have put up here is not with lipsync yet. It's just the x-sheet. Just adding and so on because I wanted that to be used and tested before I added audio. Or maybe that's [fault?] from my side? I thought it would be best if it was tested and made robust before we added sounds.

Connor] No I don't think that's a bad idea.

David] The the that is 1119, it has no sound, no scrubbing. But I have another branch with scrubbing that I would make a PR for later as an enhancement of the x-sheet. That was my plan because I think it was in itself almost like a new timeline. It's like an old-school timeline. So I thought it was such a big thing so I divided it in two. So it's just the x-sheet right now that's being reviewed.

Oliver] Yeah okay. You also mentioned something about the sound or the audio scrubbing being slow or something right?

David] It works fine in Linux and Mac, but not on Windows. There's some delay or whatever it is in Windows. So when you scrub on Windows you can hear like cli- clu- ugl- cli- clu- ugl-. But nothing if it's Linux it's just like hearing the sound. It's like stutter or something in Windows and I can't figure out what's wrong. It's the same code, same wav file and so on. But I mean 80% of our users use Windows so we have to get it working there [laughs]. Unfortunately.

David] Yeah definitely. It could be something [cast?] issue [?], or something about the audio not initiating properly or something. But I mean yeah we can look into that on a later-

David] But I just found out a couple of days ago, when I made this scrubbing, I started a media player, but our system has something called a sound player which is in fact a cover-up or something for media player as I see it.

Oliver] Yeah basically-

David] Is it better?-

Oliver] -every frame consists of a media player. Every audio frame. That's why. And it's neat because sometimes you can overlapping sound frames then you have to start a media player for each frame.

David] Okay so I should rewrite the thing I've done to use the sound player instead of media player. Because the thing with the media player is that it was the last audio file that was loaded that you could scrub. You couldn't hear the other ones. But if I use sound player I can all the loaded sounds. Is that correct?

Oliver] Mhh.

David] Mhmm. [ha]

Oliver] I'm not quite sure.

David] No I'm not. I tested. Let's go on.

Oliver] Yeah.

David] It's not-

Connor] So we're agreeing that-

David] Okay-

Oliver] But just to be clear. So the x-sheet feature could get in.

David] The x-sheet feature could get in, and it has no audio in it yet. You could import I think, you could import Papagayo files, but you can't hear the sound scrubbing and so on.

Oliver] No and [?] something about the sound or the vocal you add in the x-sheet. You know to tell what sound it's supposed to be. That is not saved right now in the project right?

David] Yeah. That's right. Probably because you can't screw up, so you can't add something to whatever you import.

Oliver] Okay so that's maybe something that we should also look into so you can add vowels or something and save it in the project file and you have it later. But I mean it's not critical right now.

David] No, no not critical.

Connor] Is the Papagayo file being saved to the project file right now?

David] No it's just opened and whatever letters you've written are written in the x-sheet.

Oliver] Temporary.

David] Yeah. So the Papagayo files has some way of stating what frame every a and b and c are placed on and then it is placed in the dialog track on the x-sheet. That's what is done, nothing else right now, as I remember it. It's a long time since I looked into it.

Oliver] Yeah also Jose talked about mentioning something about timeline being slowed down by the x-sheet because of...I don't remember what it was but I believe we did improve that.

David] It's because there's a lot of connects and they are running even if it's not shown or. That was one thing-

Oliver] But we did [?] right?

Oliver] [We did improve that?] so

David] Some of it yeah, but the other thing is that it is redrawn so that has to be worked on as well. I don't know...

Connor] So it seems like-

David] I can't really remember it

Connor] -it's kind of an important thing, especially if it's still doing that when the dialog is hidden. Is that something you want to work on before the next release, or is that something we should leave?

David] I think the x-sheet feature should wait for the next release, 6 or 7 or whatever it's called cause there are some things. I would like to look into it again.

Connor] Okay yeah.

David] Yeah. The copy move and so on, I think I'm really waiting for that to be [laughs] merged. I can see I made the PR the 11th of October, a year ago. But still, it has to be done right, so it has to wait for the undo/redo thing. But it is a thing that I and many users are really looking forward to I think. And Jose had an online session in was it in November last year or December, where he showed this feature and probably some people think well, what did became of that? Well maybe that's just me.

Oliver] No I agree. I think it's definitely a feature that people definitely ask for.

David] Yeah.

Oliver] So it will become very good once it's in.

David] Yeah. I think so too. So if it's possible, and if it's tested thoroughly then maybe the next release here. It depends on how much there is to the undo/redo thing that has to be implemented in the code I think.

Oliver] Yeah. Also I considered the possibility of us bumping the version to major because if the undo/redo branch does get in for the next version, then it should kind of be considered a major thing for the stability of the program.

David] Yeah fine with me.

Connor] I don't know. I haven't given that much thought.

David] No.

Oliver] No I mean we usually just increment by one minor right, but that also often includes just small features and bugfixes, but a proper undo system is a big step for the whole application in my opinion.

Connor] Well, to us developers and to people who've seen the code involved I'm sure it seems like a very big but to the average user it probably just seems like we've just add the dialog or the new dock widget right?

Oliver] Yeah okay that's true.

Connor] But I'd be open to bump the major if we can agree on that. We'd probably have to talk to Matt about that too...if we can get a hold of him. [laughs]

David] [laughs]

Oliver] Yeah I mean it's not something big, it's just considered.

David] Yeah.

Connor] Well Jose here is asking about the bleeding fill regression and future coloring features. [?]

Oliver] Yeah those two are mostly based on the color feature David has been working on right?

David] Yeah. As I said once, I really think for doing super professional things, this Pencil2D only needs two things now and that's: a better coloring system, and a camera I can use for something. That's my opinion as a veteran animator. But I know there's a lot of other things, stability and all that, but for me to use it professionally, that's the only two things I miss. I really hope this bitmap coloring is being merged at some point. But I can wait. I mean I can always use my branch and do the coloring I need [laughs]. So like other things it has to be done right. It should be tested thoroughly and we should agree upon how it work and so on. Of course we should.

Connor] Yeah. So I think the bitmap coloring, there's a lot of things that it changes quite significantly right so I think it needs to wait until after the undo/redo branch in the next version.

David] Yeah yes. Fine fine.

Oliver] But I mean, you're welcome to, just as we've talked about previously, trying to merge the undo/redo branch into that one, possibly making a new branch for that specifically. And trying to get that in because as far as I know or see, it should only be a basic bitmap and vector, or bitmap changes for this one. So you should be able to implement that and it should work.

David] Yeah. Sure.

Connor] Has anyone worked on the bucket fill behavior?

[silence]

Connor] Yeah I'm going to take that as a no.

Oliver] Yeah no I looked into the old code and tried to figure out how the algorithm works, it's a bit difficult to get it all down because it's all over the place in the very very old version where we did have this bleeding fill where we could you know press the same spot multiple times and it would increase pixel size.

Connor] Right and that's kind of a mess still in parts.

Oliver] Yeah. But aside from that I've only made a branch for some other feature I was working on, I can't remember it right now where I significantly improved the filling time. So you could fill say a 5000 pixel bitmap in under a second, where it would take five seconds before. But yeah, minor stuff.

Connor] I wasn't aware that was a problem, but I'm actually kind of curious what you did there. So maybe send me the link branch or something sometime.

Oliver] Yeah sure.

Connor] I know this was quite a while ago, but I did have a PR, not for not fill expansion or anything like that, but an alternate solution. I'm just trying to find it right now. I know that didn't fly but it could be something we could re-look at if that's a feature we want in the next version, I mean it's already finished right?

David] Yeah.

Oliver] Yeah I mean what else? Oh yes I have also worked quite a lot on the mypaint branch, and it's still quite heavily in progress. And I just discarded a lot of progress because I realized the way I did it was unnecessary. So right now I have a new branch called mypaint_no_bitmap_surface I believe it's called, which should work a lot better than the current version, but is still heavily work in progress. And I also discovered it's quite slow. It's as fast or a bit faster than the old feeef branch but it's still very slow in my opinion.

Connor] Do you think that's something that can be fixed or is it just mypaint?

Oliver] Yeah. Some of it is definitely the calls to mypaint. Even if we have the source code now, it does look like some things just take a lot of time. We can probably optimize some of the brushes by trying to lower the overheads of the a lot of the things you can do in mypaint, but yeah I kind of think that it needs to be customized, which is also why I forked an older version of mypaint for that to be possible. Which I mean considered the alternative is that we make a new brush engine, that's probably alright, but it definitely needs to be improved in performance to become good enough.

David] Yeah.

Oliver] Okay so-

Connor] So to go over what I've got down here in the outline. What we've agreed upon is for the next version: undo/redo, preset, relative visibility, numbered image import improvements and change the building. Yes?

Oliver] Yeah.

David] And the movie import, what about that?

Connor] Oh yes and a question mark next to movie import.

David] Okay. That's what we talked about yes.

Connor] Okay with that settled hopefully for now. When the question is now. When do we want to try and get this done for. I mean right now I think it's mostly dependent on the undo/redo branch and how long that will take to finish and review. Yeah, I mean how long do you think we should try and take for that?

Oliver] I'm going to Rome not next week, but the week after. Then I'm going to be away for the 17th to the 24th but I'm also going to work on it before leaving. So I mean sometime hopefully in October I would hope to see it done. Maybe even before. And then it's a question of you guys not any more bugs.

David] [laughs]

Oliver] And yeah reviewing the code.

Connor] Yeah and that will probably take a while. I know we've agreed that there should be two reviewers for large code changes. But for the undo/redo branch, I think there should only be one. Simply because it's large and Matt isn't active right now. I mean David if you want to review the code the code that's totally welcome too.

David] Yeah but no I don't think so.

Connor] Aww why not?

David] Well of course I can look at it but I mean sometimes when I look at the coding you do, I can't even understand it. I say this looks fine, what is he doing here? So I don't think I'm going to be a reviewer. Maybe sometimes, someday, but not right now. I can't [?] remember there was one thing I looked at where I said this, maybe I could. Maybe it was the improved numbered image import that I looked at and said well I can review this one. But a big thing like undo/redo, I don't think so.

Oliver] I mean nothing has to be reviewed in one go.

David] No.

Oliver] Definitely take your time and do it and [you can always?] just look at small spots in the code and see if you find something that is either weird or the coding style doesn't comply or something.

David] Sure sure. I could do that. Yeah. Well maybe I should try it. No harm done. I also, now that I think of it, I looked at the code for the presets support. That's why I wrote that I think that it should be hidden unless the user actively chooses it because I think it's active from start isn't it?

Connor] It is but it won't show up until you've added a preset, and by default there's no presets aside from the default. So it technically doesn't show by default.

David] Okay as long as only default is there it doesn't show. That makes sense. Yeah fine. Okay.

Oliver] Yeah and I have a few questions about that one because I think that it's not so obvious what happens when you change the preset considering that often a preset is known to be changing a lot of the UI or at least you can see the changes, where when you change presets here I'm not sure what I'm changing unless I know what I'm changing.

Connor] Yes. It is a bit challenging because it's difficult to compactly explain the concept that what you currently have is going to be saved and loaded next time you start up but I was thinking of trying to like write some tooltips and maybe changing the button [text] to make that a little bit more. I'll update you on the PR when I've figured that out, hopefully.

David] I remember I wrote a suggestion that you could have a help button or a link to a help message box because as you as you read what it does then it's easy to use and you don't think of it more. I mean it's just first time and you look at it and say what is it doing? So it shouldn't have a lot of text all the time I think. But yeah there should be some way to get help the first time you use it and then you've go it.

Connor] Yeah I think there would be a lot of features benefit from a help button.

Oliver] I mean it may not also be necessary because we could, as an enhancement you know, also make the layout not only be global but you know be dependent on the project itself. Then it would also be a lot more easy to see. So if suddenly the workspace also starts changing when you change preset, then it's more obvious. But that's an enhancement.

Connor] Right.

David] Yeah. Okay. So a month more for the undo/redo, maybe. With some luck.

Connor] Plus reviewing.

David] Not too many bugs. [laughs] And then we have these four that we agreed to merge, well three maybe four. And then let's see if the copy move reverse thing gets in and anything else. Maybe layer merge could get in. Code wise it is not a big thing but it has to be redoable/undoable. The same with the line color. It's not codewise a big thing but it should be possible to undo it. So there are two, three, of the PRs of mine that maybe could get in if time allows it when undo/redo is implemented and merged I think.

Connor] Yeah.

David] But as it is now we have three or four.

Connor] Yeah maybe if they're already updated to the undo/redo, the smaller ones particularly could be added as well.

David] Yeah. And I think as I said, changing the line color and the layer merge codewise are not very big. Well we'll see when we get there. I'm going on holiday from the 11th to the 26th of October, so I'm away at the time when the undo/redo is finished it looks like. Bad timing but nothing to do about it. That's how it is. I'm going down yonder to Australia.

Connor] Cool. Well one last call for anyone that has anything more to add about the features for v0.6.5, or the timeline or anything else we've talked about so far.

David] No I don't think so.

Connor] Alright then. I added this section to the agenda. I thought it would be kind of cool, well "cool" to have lightning rounds, or just like a couple minutes each where we can talk about some miscellaneous idea that's quick to talk about and that we would not have a place for anywhere else in the meeting. So the first thing I wanted to talk about is clarify the review policy and suggesting a PR labeling idea. So I already kind of touched on this a bit, but there was a bit of confusion earlier about the number of reviewers those needed. We did agree last time that small PRs only need one reviewer, and my quick idea is to create a new label for PRs that we do consider small just so that right away we can tell how many reviewers are needed for it. So it would be like a one-review or a small-pr label.

David] Okay yeah. Some you add or?

Connor] Yeah I can add that, it's just a quick thing to add it to the Github. But we would have to agree on which ones get that label.

Oliver] I think it's a good idea to label that. And if you can't do it yourself as the person making the pull request, for example David right now because he doesn't have permission to do it, then any other team member can do it.

David] Yeah.

Connor] Alright. I'll go ahead and add that, and maybe start labelling some if there's any that qualify for that. It kind of segways into my next idea, last idea I promise. I know we talked about this last time, I just want to ask again if David, you want to be part of the developer Github team? Because I know you were having some issues recently assigning issues to yourself and I think that would resolve that. I know you were worried about the responsibility of having write-access to the repository, but I don't think, well I'm not too concerned about it. Git is pretty forgiving I guess when you know how to use it. And I don't know, Oliver are you concerned about that at all?

Oliver] No. I think it's fine.

David] Yeah and the more I get to know Github, I'm not that concerned anymore. And I can't remember the first time but not long ago I looked into this movie import and then suddenly you have a PR. I think it would just be nice if I could assign myself to something so you know that I work on it and maybe you were Connor you work on it too and so on. It would be a waste of time. So just for that reason it would be nice to have access.

Connor] Yes and I mean I probably should have assigned that to myself too but typically for things that you know I'll do in a day or two I don't bother. But yeah.

Connor] So then we agree that you want to be part of the organization? Make it official?

David] Yes. Yes. Yup. Now I remember I had this list, I printed it out with this small small recurring list that I think Jose made and it was difficult for me to get [?] which were spoken for and which were free to work with. It would be nice to say, well now I'm looking at this and so don't bother you others. That was the other thing that I needed some access. So yes, I am officially member now [laughs].

Connor] Congratulations.

David] [laughing] Thank you.

Connor] Alright so that's concludes my lightning rounds. David you wanted to talk about the camera manipulation.

David] Yes I think it's a, I don't know precisely when, but I think it's a couple months ago I saw that Oliver had written something about the camera and that's one of my big things. I mean I don't agree with Pencil2D and the camera. I can't really use it. I mean I want to make things in HD, 1920x1080, but when the screen is that size I can't see the screen when I want to make camera movements and I don't think it should be done that way. It should be done like Oliver presents it here. You should be able to zoom in and out like in the other bitmap layers. And there should be there this thing that shows what the camera size is, and then that would be it. And then if you want to have some camera movement from frame 50 to frame 100 then you add it a frame at 50 and that would be the same as number one so no camera movement there, and you would add one at 100 and you would move the camera frame and tilt it and whatever you want. And then when you do that there would be a line from the center of the the first camera position to the center of the next, and then you could do it so instead of a straight line, it could go by some curve and you should be able to choose yourself if it was ease-in and ease-out or if it was evenly spaced and all those things. And it shouldn't be that, I mean it's probably more than I could. I haven't succeeded yet, I have worked a little on it, but I don't think it should be that hard to do and it would be more logical to use. Right now you have the camera as a fixed thing and then you move the backgrounds instead. It's quite the opposite of what I think is logical. I think you should move the camera to zoom in or zoom out or pan whatever you want to. And then the drawings, your backgrounds, your animations, should be where it is, and the camera should move. So, but of course if you haven't read the thing, I mean you have now but if you didn't see it at that time, that's obviously the reason you haven't commented on it. But the camera I think that's a really important thing for Pencil2D. Much more important than...yeah mypaint just to say one thing. Mypaint has been wanted for a long time and so on and it's an important thing too, but we need a decent camera. And I know it's hard to say that the one we have now is not decent because we can make camera moves and we can get it to focus on part of the background, and we can export videos and so on, but it's not very useful. I have so far I've only used fixed camera positions. I don't want to think in the camera moves as long as it is now. I'm sorry to say but that it. I can't cope with it [laughs]. So that's why-

Oliver] I think it's a-

David] Yeah?

Oliver] Yeah I think it's alright David. I mean I'm pretty sure we all [?] the camera manipulation right now is kind of rough and not the best thing to showcase when showing Pencil2D because while it's, what do I say, it's a bit organic because you just go to the camera layer and apply changes. It's also too much control and it applies right away. You have no way of knowing when you modify the camera or you don't know explicitly. It's kind of implicit on everything. So I definitely agree, it's why I made the proposal to make the camera more of an object. Also because in the future it would be nice to get the bezier curve, being able to tween in motion and all that stuff. And that will be much easier if the camera is considered a tangible object.

Connor] Yeah. I've only really skimmed the document so far, but from what I see it looks good. I agree the we're currently dealing with the hand tool is a pain and has caused a lot of issues with people not realizing they're modifying it or not understanding that they can modify it. I think that what's proposed will make that a lot more clear. So I'm definitely in support of changing that.

David] Yeah is that something I should look into or work on? I have looked a little into it but maybe it's above my capacity. Because you should be able to zoom on the camera layer I think like the other layers so you can go to a big screen. So you start with a field that is maybe 6000x2000 pixels and then zoom into something. And then you have to be able to zoom out to do that. To really get in the picture what you want. And that's the thing I miss. You can't really control it. The zoom is not precise enough as it is now and yeah it is not logical what you do basically.

Oliver] Yeah that's another thing we came to discuss some time ago that you have know control of zooming precisely except if you have a trackpad or if you use one of the fixed zoom levels. Then I made an issue on possibly having a zoom tool, but that may not be a good solution either. Jose mentioned that he doesn't like a specific zoom tool, but we definitely need the ability to allow precise zooming.

David] Yeah. Okay, this should be a lightning conversation so I just think I'll spend some time on it, see if I can get anywhere.

Oliver] Yeah you're welcome to look at it. I mean I tried to note down a lot of things about how it should work so you can always and [me?] to clarify something or yeah.

Connor] Yes these changes would be welcome I think.

David] Yeah.

Connor] So our next lightning round. I don't know who put this there cause they didn't put their name.

Oliver] [whispering] I did it. Write my name.

Connor] Okay Oliver. Take it away with your idea.

Oliver] Yes. It's basically something I've thought about for a while that right now we have a fixed number of developers in the About dialog. And I think we should credit our developers more and also just one-time contributors and all that just to see that we actually have quite a bunch of people being involved with the program. And my thought about that one was to simply get the names that will appear when you do [?] git. Which I believe we can do something so you can get all of the contributors with git. And if that's possible then create a script or something that adds that into the text which can be run maybe automated for each time we make a release or something.

Connor] Yeah I think that's a fine idea. If you want to take it another step you could also get the contributors Transifex, the translation platform we're using.

Oliver] Yes we are.

Connor] And I'm not 100% certain but I think there were some contributors that are not in the git history from before Pencil2D was forked. I don't know if you want to look into that. I'm sure it would be some fixed list that we could add.

Oliver] Yeah definitely. I mean we do already have some like Naidon and Patrick Corrieri which are some of the very old developers, even before Matt I believe. We also have a lot of new developers so I think it's nice to [?] that those also exist and definitely also helped making the program it is today. Even if those changes are small or big, it doesn't really matter, it's just mentioning everyone involved.

Connor] So- sorry go ahead.

Oliver] Yeah. I think I will try to do something about that one. See if I can get names, make a script, and make it possible. I'm not sure when that's going to be but I will note it down. And probably maybe should.

Connor] Okay, looking forward to that. Do you think there should be any particular ordering to them. Like just alphabetical or should we try and take the amounts of contributions into consideration somehow like number of commits or number of lines changed or anything like that?

Oliver] No. I mean you could do that and also believe possibly that we should keep the current ones at the top and then just mention all the other contributors by ascending order. But I don't really consider the amount of [comments?] very important.

Connor] Right. It could be chronological too.

Oliver] Yeah.

Connor] Well just something to think about. Anything else you guys want to talk about or should we wrap it up now?

David] Another thing I have looked into is like layer merge. I have a layer import if you could take an project file and open it and see just to take one or two layers from that one if you want to use some animation. But I find it very hard to see whenever it loads and finds these layers. So I don't know. You know the code better than me, is that something that's possible. I mean [some?] not too hard to do. What I thought was, you could choose a scene and it would show what layers are in the scene and you could click on the box and then say import. And the boxes you have clicked would be imported. That was what I thought it would do but I gave up at one point. What do you say?

Oliver] So you want the ability to copy elements from another projects?

David] Yeah. It could be a character or something, it could be snow, it could be rain, it could be thunder that I want to reuse in another scene. Of course I could export all the pictures and re-import them and so on but just to have an import layer from project file, that would be nice I think.

Oliver] Oh I think it's a [better point?] and I think it would be a good thing to have also. Probably just like you can import a Photoshop file in Photoshop, you can also import a Pencil file in Pencil2D and then you could choose what you would want to import from a file.

David] Yeah.

Connor] I think from a technical perspective maybe you could-

[Connor eloquently discussing how to implement the feature without holding down the push-to-talk key]

David] I can't hear you.

Connor] Oh I'm sorry, when did I cut off there? I forgot to press the button.

Oliver] You could do something and then you cut off.

David] Yeah.

Oliver] Or something about [?]

Connor] You could create a second Object for the new file, and then copy over layers from one Object to the other. That might work. You might have to copy over the files from different temporary folders too. But that would be where I would start with that.

David] Okay.

Oliver] Yeah I'm looking into how the Object class is the main, or the bone of the whole project file so I would look into that class for what it does to add layers and all that stuff. And then possibly yeah, exactly as scribble says, make a copy of that and try to extract frames from it.

David] Okay. I'll look into it at one point. Yeah. But first I will prepare my PRs for undo/redo as good as I can, as soon as I can. Okay. Anything more? State of Pencil2D version on Linux.

Connor] Jose was just talking about how there's a variety of Linux issues coming up supposedly if I understand that right.

David] Uhmm...

Connor] He's asking if we should prioritize those in the next bugfix release which will be v0.6.6 or 0.7.2.

Oliver] So for the release after the next release right. Because v0.6.5 is the next one.

Connor] Right. Personally I don't think they specially prioritized. A lot of the issues with it right now seem to be packaging. With Linux users, they generally tend to be more competent in compiling projects and stuff like that so I am a little less concerned about them because, worst comes to worst I guess they could compile it themselves, or install it from their distro. There's a lot of options for them. If one doesn't, another one should. Having said that, I think at some point we should put more work into fix the AppImage and Flatpak issues and all that.

David] The problem with AppImage for Pencil2D and many other programs, what is it, the sound?

Connor] GStreamer.

David] It's yeah GStreamer issue. We can't fix that I think hey? It has to be GStreamer as I understand it.

Connor] Yes and no. Yes they would have fix it upstream, that would be the ideal solution. But there are some workarounds for that. If you go to the issue thread on I think it's the AppImage repository or something like that, it's linked from the Pencil2D issue on that sound issue. And yeah I think there's a couple workarounds that we could at least look at, but I don't know how good they are, or how they would work with our continuous integration.

David] Oh okay.

Oliver] Yeah there's also the states of the installer PR which J5lx worked on some point. It's still also in the PR section right?

Connor] Yes.

Oliver] It's just not complete, or?

Connor] Last I heard if I remember correctly, he was going to add some other features that weren't in there. I don't know what the status of that is, if it's close to completion or not.

Oliver] Yeah. But I mean in general it's just a very good idea to definitely focus on the package management or the distribution of the software for the platforms. Making it as easy as possible for the user to use Pencil2D, even if they are less competent or whatever.

Connor] Okay. Anything else anyone want's to bring up?

David] No. There's assigning roles. I have started working on working on user manual. I've written about pegbar alignment. And of course I'll go ahead and write about these presets and improved numbers and so on. The issues that we mean to merge in the next release. So whenever the release is, then it will be in the user manual same day or the day after. That's my hope for that at least. Is there anything else I need to be done. I would like to hear about it. I'm open for anything. Talking about the next release of course.

Connor] Well now it's looks like you've got Jose started on the topic of manuals so let's give him a moment here.

David] [laughs] Yeah. The quick reference is outdated. Yeah it's not bad but it is outdated.

David] And the person who did that, who is that? The quick reference.

Oliver] It was some contributor some time ago. I believe he only did that PR or maybe a few others.

David] Yeah okay. I looked at it at some occasions, the quick reference. It's not bad but it is outdated at various points.

Oliver] In general I think if something needs to be documented heavily, then we've failed at making the software usable or be as easy, as simple as we ought to make it.

David] Yeah.

Oliver] And of course some things need to be documented but if it needs to document something heavily, whatever heavily is, then we should also consider looking into how to improve that feature so it doesn't need to be document.

David] Well that would be the ideal but... yeah-

Connor] -that's not always so ideal right-

David] -But yeah [?]

Connor] I mean yeah there's still a few things in Pencil2D that are kind of stupid. I mean we've fixed the onion skin button in the timeline, that was a nuisance. And like changing the camera resolution, that's always been a stupid thing like oh I'm just going to try double clicking on the camera layer, see if that does it. So I mean for now at least we need to have some complete documentation, if at least for these tricky cases that users keep coming to us for.

Oliver] Yeah, I think that's a good idea.

David] But the one with the camera resolution is in the user manual now like some other things. And it will be more. And we talked about, or maybe it was a question or another suggestion, where we should have a startup picture: have you looked at the manual? Have you looked at the frequently asked questions? Have you looked at the tutorials? I mean I have eight or nine, eight I think, tutorials I made on how to use the program and so on. And many answers are in those tutorials as well. Maybe it would be good if they were met with a sign to where they could get some help, because every time we are spending time helping the users we can't document or code or whatever. It takes time.

Connor] Some programs have those tip of the day things when you start up. That just one solution like that.

David] That's one thing yeah.

Oliver] Yeah I think something like that would be a decent solution. I mean we talked about a preset startup window where we could set the resolution and all that stuff, but it was mainly we agreed that it was not a good idea. The nice thing about Pencil2D is that you just open the program and start animating. You don't have to think about anything, which we all agreed was nice. So I'm not sure a welcome screen is what we want, but I do agree [?] to look at tutorials or something.

Connor] Well that's something I guess we can just think about. How to balance, like I'm still in the same position as before that the welcome screen does more harm than good. It's kind of annoying. Probably not many people will actually read it. But I don't know, you guys can think of a better way to help people help themselves then that would be something I think we're all open to.

David] Yeah. Yes so now we wait for the redo/undo and for the final call where you say Connor, now it's next week there's a new release, or two weeks or three weeks, there's a next release. And then we have to wrap it what we have and see will get in and what will wait. And who does what when the release comes. Is that what we decide here on the way out?

Oliver] Yeah. I did actually have another comment, just quickly. While I was making the newest things on my undo/redo branch, I got a very large urge to refactor the TimelineCells class. I would just like to know if that's okay because you know I can't stand having a class or a function or a method which is over 100 lines of if statements and all kinds of stuff, it's just horrible. So yeah. I considered doing that, just refactoring everything, making it neat and tidy. Also because I started this architecture to say where if anything needs painting, then you create a Painter class for it. So like there's the CanvasPainter and there could also be a TimelinePainter. There's also a SelectionPainter so you know kind of gets the same drill of making the classes neat and tight.

David] Well you can understand you want to refactor but [I should wrote?] I think you could accidentally break something then it's not so good. But I mean it has to be done. We can't live with it forever.

Oliver] No so it's mainly a question of whether scribble agrees to that or he wants me to wait until he runs a bulldozer through everything or yeah.

David] [laughing]

Connor] Uhh. I'd prefer if you wait. I know stuff like that bugs me too, but it would make reviewing the undo/redo PR a bit more of a chore since you're modifying more of the existing code, so try not to.

Oliver] Oh no I mean I would do it in another branch, I would not do it in the undo/redo.

Connor] Oh okay, but based on the undo/redo branch, or just completely separate?

Oliver] Completely separate, and then it would have to be merged with the undo/redo changes and some point. But currently I would just make the changes to the current state.

Connor] Okay yeah you could do that I suppose. As long as you're aware it will eventually get superseded hopefully, and probably won't get merged before v0.6.5, I don't think that's a good idea. But after that for sure.

Oliver] Yeah no probably for the next release, I just want to do it.

Connor] Alright.

Oliver] [I agreed?]. No more questions?

Connor] Alright then, that seems like it's it for us. Thank you all for coming to this meeting. I'm glad that we were able to work out kind of where we are with the next release and where we want to be and when. Yeah, later!

David] Okay.

Oliver] Yup.

David] See you, bye.

Oliver] Later, bye.