Missing files are now automatically deleted from the recent menu, with a notification in the status bar (rather than a dialog box)

[itsbe-au]

Supersedes PR #1605

[itsbe-au]

Please ignore the absolute git gore that is above... obviously I had some trouble getting my branches in sync!

[ferdnyc]

Please ignore the absolute git gore that is above... obviously I had some trouble getting my branches in sync!

I've sometimes thought that they chose the name git for its ability to make you feel like one, when trying to figure out what the hell is going on with it. 😆

I'll try to give this a spin later on today, thanks!

[ferdnyc]

P.S> My GitHub branch-management process, first attempted with OpenShot but now the one I use on all projects, goes like this:

$ # After creating my fork in their web interface
$ git clone <my fork SSH identifier>; cd $PROJECT

$ git remote add upstream <upstream HTTPS URL>
$ git fetch upstream
From https://github.com/...
$ git branch -u upstream/$DEFAULT $DEFAULT # 'master' or 'develop' or whatever
Branch '$DEFAULT' set up to track remote branch '$DEFAULT' from 'upstream'.

$ # So now, the default branch tracks the UPSTREAM. I never use that branch in my own fork.

$ # When I want to write code for a PR...
$ git pull # Sync with upstream/$DEFAULT
$ git checkout -b newtopic # Create a new topic branch based on latest upstream/$DEFAULT
$ git push -u origin newtopic # I do this immediately, before writing any code, to configure it
Total 0 (delta 0), reused 0 (delta 0)
remote: 
remote: Create a pull request for 'newtopic' on GitHub by visiting:
remote:      https://github.com/ferdnyc/$PROJECT/pull/new/newtopic
remote: 
To github.com:ferdnyc/$PROJECT.git
 * [new branch]      newtopic -> newtopic
Branch 'newtopic' set up to track remote branch 'newtopic' from 'origin'.

$ # Then after committing any changes, I can just...
$ git push
remote: Resolving deltas: ...
To github.com:ferdnyc/$PROJECT.git
   $GITREFA..$GITREFB  newtopic -> newtopic

$ # After I finish development on newtopic...
$ git checkout $DEFAULT # Return to upstream/$DEFAULT as my base branch
$ git pull # Sync with upstream/$DEFAULT

$ # And if I need to return to newtopic...
$ git checkout newtopic
$ git merge develop # If there's already a PR, it's easier/cleaner to do this on the web.

[peanutbutterandcrackers]

@ferdnyc - Looked at that cool documentation of your Git-workflow. Thought, I wish there was a gist. And there was. Thank you!

[ferdnyc]

Thought, I wish there was a gist. And there was. Thank you!

(For the curious, that's this gist.)

[DylanC]

@ferdnyc - Any thoughts on this one?

[ferdnyc]

Ahh, crap. I'd said I was going to look at this, and promptly did... exactly nothing.

Sorry about that. I'm checking it out as we speak, I'll get back to you within the hour.

[ferdnyc]

LGTM. Seems to work well.

Timeout

I think the timeout on the message could maybe be longer, but that's something we can adjust after-the-fact based on feedback/testing, it doesn't need to hold up this merge.

I'm actually thinking that the ideal situation might be to display the message with a very long lifetime, almost indefinitely — like, literally a full minute, maybe more — but then also have any subsequent file-loading actions clear it out again. Which would be as simple as just having MainWindow.open_file() always set a blank status line entry, so that any file loading actions will clear out an existing message (if any).

Post-failure state

It feels a bit weird that, if you already have a project loaded when you try to open a Recent file that's no longer there, nothing happens in OpenShot other than the entry being removed and the status-line message being shown. The project you previously had loaded remains open. But, that's both consistent with the previous behavior, and probably the best course of action to take under the circumstances. (I jut said it felt a bit weird, not that it's necessarily wrong.)

Message formatting

Hmm. Possible future modifications aside, as far as the current PR's code goes my only concern is that the message might be a little verbose. With the default window size, it can get cut off if you have a long path.

I used mkdir -p /var/tmp/test/path/that/is/incredibly/long/to/read/ and saved an OpenShot project in there, then renamed /var/tmp/test/path to /var/tmp/test/location. So, the resulting message was...

Project /var/tmp/test/path/that/is/incredibly/long/to/read/addremovetracks_abspaths.osp is missing (it may have been moved or deleted). It has been removed from the Recent Projects menu.

(More of it fit in the window's statusline than actually fits here, but not _all _of it.)

I guess the options for addressing that would be:

1. Display only the filename, not the full path, in the status-line message.
2. Shorten the surrounding text to be more concise.
3. Both.

But as I said, none of this constitutes a reason to hold up the merge, it's all stuff that can be tweaked after the fact. Thanks @bnieuwveld, good stuff!

(ETA: Looks like I missed my "within the hour" timeframe by around 8 minutes. #SHAAAAME)

[DylanC]

@ferdnyc - No problem about the delay. LGTM too! 👍 Great job @bnieuwveld !

[ferdnyc]

Oh, and special shoutout to Github's hub command, which makes working with in-progress PR code a breeze:

$ cd /path/to/openshot-qt
$ hub pr checkout 2202
remote: Enumerating objects: 2, done.
remote: Counting objects: 100% (2/2), done.
remote: Total 3 (delta 2), reused 2 (delta 2), pack-reused 1
Unpacking objects: 100% (3/3), done.
From git://github.com/OpenShot/openshot-qt
 * [new ref]         refs/pull/2202/head -> bnieuwveld-develop
Switched to branch 'bnieuwveld-develop'

[DylanC]

@ferdnyc Pretty neat. Thanks!