WIP - Timeline bug fixes

[DylanC]

I hope to fix the follow issues:
#1383
#1454
#1839 (maybe if possible)
#1587 (maybe if possible)

Current the PR:
Fixes #1383

[ferdnyc]

@DylanC — I was looking at this PR (or, trying to), and I'm thinking it might be best to back it out and restart, because of those extra dirs that snuck in. Problem is, even though they were removed in a subsequent commit, in terms of the branch history they're still there (in fact, they're there twice, once for the insertion and then again for the deletion), which results in the change history being > 400,000 lines added, > 400,000 lines removed... and Github tries to crash Chrome every time I attempt to switch to the Files Changed view.

(Warning, lots of details you may already know ahead...)

I don't know if you have the project repo defined as a remote (I recommend it, it's handy to be able to reference checked-in branches — you can add it with git remote add upstream https://github.com/OpenShot/openshot-qt.git), if so then (after a git fetch upstream) you can use git format-patch upstream/develop..develop to write out all of the commits on your develop that aren't checked into upstream/develop. What you'll end up with on disk is this:

> ls -sh 
total 350M
 32K 0001-Fix-remaining-if-statements-no-code-changes.patch
 40K 0002-Fix-the-missing-curly-braces-on-all-if-and-for-state.patch
175M 0003-Make-the-markers-not-draggable.patch
4.0K 0004-Update-gitignore.patch
175M 0005-Remove-build-dirs.patch
4.0K 0006-Fix-clips-glitching-on-resize-event.patch

(Yeah, those two commits are 175MB each.)

But then, if you create a new branch off of upstream/develop (git checkout upstream/develop; git checkout -b branchname) you can use git am on each of the format-patch files to import them into the new branch as commits. (Not either of the 175MB ones, obviously. You'd have to recreate 0003 by hand, but since it's one change to one line in one file that's NBD.)

Oh, and you'd also want to do a git push -u origin branchname your first time pushing from branchname, that'll set it up as a tracking branch for your fork, and after that git push will default to doing the same thing. And when you visit the project repo on the web, Github will notice that you've pushed to a branch in your fork, and happily offer to create a new PR for it.

[DylanC]

@ferdnyc - I know. I checked in my build folders by mistake and I knew it was all too late to fix it at this point. I will have to start a new similar PR with just my changes. (Arrrggg)

I will use your idea of applying the patches. Thanks!