Check in "Save Current Frame" feature

[N3WWN]

This PR addresses the feature request made in Issue #893.

A new preview window button has been added (a camera) which will save the current preview frame (at full profile resolution, regardless of preview quality/scale settings) to the project's current directory or the user's home directory if the project has not yet been saved.

The ability for the user to add a keyboard shortcut has been included, but no keystrokes have been assigned by default.

Presently, the file type is hardcoded to PNG.

A dialog window is shown reporting where the frame was saved or that an error has occurred.

[ferdnyc]

Neat, that sounds like a handy feature to have.

Especially if this is going to bring up a dialog window anyway, though, what do you think of having it pop up a file-save dialog and allowing the user to (a) name and (b) place the file however they choose? (It could start at the default output directory, and be pre-filled with the default filename, but this way the user isn't forced into either of those.) Then the results popup could be dispensed with, as the file-chooser dialog effectively serves as their notification.

I'm not too wild about just dumping the file into a set location, without giving the user control over that location. Nor of forcibly overwriting previous output files without warning. The user may very well want to do something like, say, save the same frame# multiple times as they make changes to their project, then compare those different versions.

(I also just hate message boxes. In general. Especially "everything's OK!" normal-status message boxes. The way I see it, if a piece of software is going to interrupt my work with something I have to acknowledge before I can continue, it had better be damn important. "I successfully did the thing you just told me to do by clicking an icon / pressing a keyboard shortcut!" is never going to qualify. It's not like this should be news, or come as a surprise to me. I'm the one who requested it, I want to be able to assume that it was done! There's no message box for "I just zoomed in on the timeline!" when you click "Zoom in". The only reason an application should bother me with the results of an operation I triggered is when something goes wrong and it isn't completed successfully.)

[peanutbutterandcrackers]

I wonder if we could come up with a more subtle-er status indicator. Perhaps make the icon change to show a check mark or a cross mark for a few seconds to indicate whether the save has failed or not? Also, is it possible to have the 'grab frames to this directory' part in the preferences? And also have an option to save into a folder called 'screengrabs' or something in the current directory where the .osp file resides?

Sorry if I'm asking for a little too much... :D

[ferdnyc]

I wonder if we could come up with a more subtle-er status indicator. Perhaps make the icon change to show a check mark or a cross mark for a few seconds to indicate whether the save has failed or not?

The traditional location for such reports would be the status bar. You throw a message like "Saved frame $number image to file $path" down there, and the user can read it or not, but they're not forced (or able) to interact with it in any way.

Status bar messages (and status bars in general) have been falling out of favor, but the current OpenShot main window layout does include one. (At least, it does on Linux. So I'm guessing it does on all platforms, since Qt is pretty consistent about that stuff.) To my knowledge, at the moment it's completely unused.

Also, is it possible to have the 'grab frames to this directory' part in the preferences? And also have an option to save into a folder called 'screengrabs' or something in the current directory where the .osp file resides?

It's possible to have anything in the preferences, but:

1. You'd really want that to be a per-project setting, not a software preference. There currently isn't a general interface for project settings. The few we do have (profile, export/import directory, current zoom, a few others) are either implicitly set by user actions, or each have their own location in the interface.
2. "In the current directory where the .osp file resides" has no meaning if the project hasn't been saved yet.
3. It doesn't solve the overwrite problem (where the user wants to save multiple different images of the same frame number).

[N3WWN]

@ferdnyc :

...pop up a file-save dialog and allowing the user to (a) name and (b) place the file however they choose

I hadn't considered this, but shouldn't be too difficult to implement consistently as this is implemented elsewhere in OpenShot.

...dumping the file into a set location...forcibly overwriting previous output files...message box...

I was attempting to make the frame grab as simple as possible, so dumping to the project directory or the user's home dir (which is also the defaults used elsewhere in OpenShot) seemed reasonable, at the time, but the overwriting of previous files should be handled better.

The message box was so that the location of the frame grab was announced to the user (upon success) or that there was an error (upon failure). I considered those "damn important" 😆 I don't see a need for a dialog or notification of a change in zoom because the change is immediately apparent to the user as the visible timeline duration changes (self-evident).

@peanutbutterandcrackers and @ferdnyc

...in the current directory where the .osp file resides...
"In the current directory where the .osp file resides" has no meaning if the project hasn't been saved yet.

The directory where the .osp files resides is the default for saved frames right now, which fails back to the user's home dir if the project hasn't been saved, just like the behavior that OpenShot exhibits for .osp files and exported videos.

@ferdnyc

...status bar...OpenShot main window layout does include one...

I don't see a status bar on any of the instances of OpenShot that I've ever tried (starting at 2.3.x and up to the current dev versions). I only use AppImage/dmg releases on Linux and Mac OS X, so perhaps status bars aren't available in those. 🤷‍♂️

I do think that the save file dialog is a good idea, with more reasonable default filename (something like frame%04d.png instead of %d.png) and file overwrite detection.

Again, not sure how soon I can implement these changes, but hopefully very soon! I'm not expecting these to come out with 2.4.2, so it's not like there's a rush. 🏃 💨

[ferdnyc]

I don't see a status bar on any of the instances of OpenShot that I've ever tried (starting at 2.3.x and up to the current dev versions). I only use AppImage/dmg releases on Linux and Mac OS X, so perhaps status bars aren't available in those.

Huh, really? No, sure you do! There's one in your screenshot in #876 — as well as in @peanutbutterandcrackers' screenshot from that same bug.

Like I said, it's not used for anything in OpenShot (currently), but the reason the main window has such a thick bottom border is that the bottom border is actually a status line. It's been sitting down there ignored and unused #ThisWholeTime, given no purpose except to hold the window-resize handle.

(Plus, I cheated and loaded the .ui file in QtDesigner. It's part of the default layout for the QMainWindow widget that OpenShot's built from — statusbar can be disabled, but it never was. It's just that the only place it's ever referenced anywhere in the codebase, currently, is that UI file.)

[N3WWN]

Huh, really? No, sure you do! There's one in your screenshot in #876

Oh man! Color me dense! I always thought that was dead space that was part of the timeline!

[ferdnyc]

I wonder if this should use, and update, the project export_path, instead of always starting at recommended_path? Or perhaps even add yet another project file variable, to track snapshot_path or whatever?

(See #1372 which created import_path to track last-open-location for "Import Files...". But export_path already exists, so you could just use that. Assuming users won't be annoyed that their exports and their frame snapshots affect the other's starting location.)

If nothing else, subsequent invocations of the dialog within the same session should endeavor to start in the same directory where the previous file was saved. Making the user navigate there from recommended_path every single time can seem cruel, especially if they have to traverse a long path to the intended destination. Doing that once is tedious. Having to do it more than once feels like abuse.

Whether that persists beyond the current session... up to you, I don't really have an opinion on that.

[DylanC]

@N3WWN @ferdnyc - I take it there is more work to be done for this PR?

[N3WWN]

@DylanC - I think I've addressed the concerns/suggestions EXCEPT the default path.

I'll try to get the path issue sorted today.

[DylanC]

@N3WWN - There is no pressure. I just wanted to know where it was, as I couldn't follow the conversation very clearly. 😆

[N3WWN]

@DylanC - Don't tell me that! I'll put it on the back burner and never get to it! j/k 🤣

Okay, just checked in the commit which uses/updates the export_path consistently instead of defaulting to the project path (or HOME_PATH) each time. This was actually easier than I thought it would be. 🤷‍♂️

If you're good with this PR, and @ferdnyc and @peanutbutterandcrackers wanna sign off on it now that all items are addressed, I think we're good to go!

[peanutbutterandcrackers]

I do have a few thoughts regarding this feature. Sorry if this is a little too much.
[Note: All screenshots are taken on an Elementary OS 0.4.1 'Loki' Machine.]

1. The camera icon's position:
   Perhaps it'd be best to keep the camera icon to the right side and keep the navigation icons centered?

2. The camera icon itself:
   Perhaps we could use a darker icon? A dark symbolic one, maybe?
   

3. The camera icon - enhancements:
   Perhaps we could have a drop down in the camera icon like the save icon in LibreOffice.
   
   And, if we could have that drop-down give the user some frame-capture settings?

Some ideas for the settings:

Naming Scheme settings:

Perhaps have different name formats be available to the users as options? Like

• frame#x - where x is the number of the captured frame in the clip itself (like it is now)
• frame#y - where y is the number of the captured frame in the current project?
• Custom naming scheme, perhaps? With string specifiers and all. %D for full date, and all. Like a lot
  of other *nix programs?

Default Save Location:

Maybe have a few options like the following:

• The same location where the .osp file resides. Inside a subfolder called 'screen-captures'
• Some other location specifiable by the user

[peanutbutterandcrackers]

Currently, even if the project is saved, it keeps on opening a pop-up and offers to save in the home-dir. I think I like the idea that this pop-up also keep track of the last directory used. However, if possible, I'd like the feature that I suggested in the comment above - to specify where the screen-grab should be kept. At least, for a saved project, a 'screen-captures' (or sth similar) directory in the same directory as the .osp file would be just great.

I know I might be asking for a little too much. Sorry.

[N3WWN]

@peanutbutterandcrackers

The camera icon's position

Okay, it took a little figuring out, but I was able to get the Save Frame icon right-justified while maintaining centered playback controls:

The camera icon itself

As you can see, I've used a dark icon instead of a light icon. Not sure if this is something that could (should?) be changed with the theme? Dark theme = dark icon and light theme = light icon? Regardless, I think this could be a future enhancement. I'd like to get the functionality into OpenShot first and we can tweak the appearance in different themes later.

The camera icon - enhancements

I'm not sure how much extra juice we'd get for the proposed icon enhancements squeeze. 😁

Frame x and y:

The current frame number behavior is currently how you describe the "Frame y" capture working.

It is not possible to capture the frame from the clip (Frame x) with the current implementation of Save Frame since the frame in OpenShot is the (pre)rendered output frame. To capture just the previewed frame of an existing clip, a new timeline would need to be created, the clip added to the new timeline, possibly along with any cuts so that the current playhead location in the clip could be determined within the new timeline, and then the frame saved from there. We then have to ask if any other clip-specific changes should be applied on the new timeline (fades, effects, etc). If someone wanted to export a specific frame from a clip (not the timeline), I'd recommend they open a new project, import the clip that they want the frame from, locate the playhead accordingly and save the frame from there.

Another way of accomplishing the same thing would be to add the ability to disable tracks. You'd then have to disable all track except the one with the clip you want a frame from, save the frame, and re-enable all of the tracks again.

Custom filename formatting:

I doubt that folks will be using the Save Frame feature to export the many images that adding custom formatting would be useful for. If someone wanted something like you describe, I'd recommend they create a new folder, name is with the current date, and then save the frames in there. The user has the ability to override the default saved frame filename in the dialog, too. If they do that once, for the next saved frame, they can click on the first one, which would prepopulate that filename and then adjust the frame number.

Default save location:

The default save location is supposed to be the same directory as the .osp file (for saved projects) or the user's home directory (for unsaved projects), just as you're asking. This should also be the same behavior as the Export Video dialog and the Import Files... dialog.

• I do see that it defaults to the user's home dir regardless of whether or not the project is saved or not. I'll dig into this.

Once a frame is saved, that directory will be used for additional saved frames (or exported videos) - I know this is working.

The user can specify any directory they want using the Save Frame... dialog. If they want to create a "screen-captures" directory, they may do so and, if they save a frame there, the next frame they want to save will be saved in that same directory. Is that sufficient?

I'd prefer not to create directories automagically (where would they be created for unsaved projects) that the user may not want to use because we'd either have to clean them up or leave the clutter laying around.

[N3WWN]

Default save location (for when a project has been saved) is now fixed.

Icon is now right-justified and swapped out for a darker version. I left the light version icon in the PR since we may want to change from dark to light icons when the theme is changed.

@peanutbutterandcrackers - Mind taking another look, sir? 🤞

[peanutbutterandcrackers]

I'm sorry it took me quite a while to test it out. Here are a few things that I think could be improved (just my humble opinion).

1. The icon, again. Sorry to be such a nag about it. But I would like to present this icon as a probably better candidate for the final icon. Or, something similar. A symbolic dark camera icon. I found this on my Linux Mint 18.3 machine under '/usr/share/icons/HighContrast/scalable/devices/camera-photo.svg'. Or perhaps this? Or maybe both - as light and dark versions? I wonder if, the latter icon, because it is grey in color, could be used with both light and dark themes just as well? Just a thought.
2. The save-location. It seems that as long as the project isn't saved, it defaults to the last place saved. But, if I have the project saved in a directory and create a sub-directory for the screen-grabs, and save one inside that, it doesn't remember that last directory where I saved the screen-grab. Perhaps it would be better if the last-save-location took precedence.
3. This might not be a real issue, per say. But for some reason, automatic transition (when I stack one picture on top of another) wasn't working for me in the HEAD of this branch. I think that is an issue that might cause problems later on.
4. For some reason, I am unable to assign a keyboard short-cut to this action. Perhaps this needs to be added?
5. I wonder if the naming scheme could also be a bit more descriptive. If we could somehow keep track of the number of the current screen-grab i.e. whether it is the first screengrab or the second one or the third one and add that to the end of the name, one could have duplicate frames but that would still have a unique name. Just a thought. I know this might be too much though.

[N3WWN]

The icon, again. Sorry to be such a nag about it. But I would like to present this icon as a probably better candidate for the final icon. Or, something similar. A symbolic dark camera icon. I found this on my Linux Mint 18.3 machine under '/usr/share/icons/HighContrast/scalable/devices/camera-photo.svg'. Or perhaps this? Or maybe both - as light and dark versions? I wonder if, the latter icon, because it is grey in color, could be used with both light and dark themes just as well? Just a thought.

I've updated the icon to the camera-photo-symbolic icon.

The save-location. It seems that as long as the project isn't saved, it defaults to the last place saved. But, if I have the project saved in a directory and create a sub-directory for the screen-grabs, and save one inside that, it doesn't remember that last directory where I saved the screen-grab. Perhaps it would be better if the last-save-location took precedence.

Ack - I don't know why this has been such a pain. Probably because I'm multitasking with other stuff. 😞 I think I finally got it fixed.

This might not be a real issue, per say. But for some reason, automatic transition (when I stack one picture on top of another) wasn't working for me in the HEAD of this branch. I think that is an issue that might cause problems later on.

Not an issue with my N3WWN dev branch (https://github.com/N3WWN/openshot-qt/tree/save_frame-Issue_893) - is that the branch that you're using the HEAD of?

I just tested with taking multiple pictures and either dragging and dropping them from the Project Files frame to the timeline with an overlap, or moving them to cause an overlap after having previously added them to the timeline.

For some reason, I am unable to assign a keyboard short-cut to this action. Perhaps this needs to be added?

I just set mine to ` and it worked perfectly. I then changed it to Ctrl+Shift+F, restarted OpenShot and that worked perfectly, too.
Did you restart OpenShot after binding the key?

I wonder if the naming scheme could also be a bit more descriptive. If we could somehow keep track of the number of the current screen-grab i.e. whether it is the first screengrab or the second one or the third one and add that to the end of the name, one could have duplicate frames but that would still have a unique name. Just a thought. I know this might be too much though.

Keeping track of the number of saved frames would add another value that needs to be maintained in the .osp file. What would the use case be for saving the same frame over and over where it would be much more efficient to have the file name autoincrement the # of saved frames along with the frame number?

The juice has to be worth the squeeze. 🍋 😉

[peanutbutterandcrackers]

Awesome!

The symbolic icon theme works great, I think. :)

Yes, that is the branch I was at the HEAD of. Strange. It works well now on this Elementary OS 0.4.1 machine. It didn't on another Linux Mint 18.3 machine yesterday. Oh well. Either ways, nothing to worry about, then. :)
Same with the keyboard shortcut. I didn't see 'save frame' option in the preferences on LM 17.3 yesterday. But now, on this El OS 0.4.1 machine, I can. So nothing to worry about here, too.

True. I think it's okay to not have auto-increments in the file name, then. I just thought if someone would want to export multiple frames and would want to ffmpeg them all? I don't know. But it's okay to leave it out. :)

This feature now also remembers the last place I saved the frame to, even if the project is saved. However, for the first frame, it defaults to the home directory - even for a saved project. Could you please make it default to the directory where the project file resides if the project has been saved? I'm sorry I've been quite nag.

You're awesome, BTW. You're seriously awesome! 👍

[peanutbutterandcrackers]

Strange, now, on the LM 18.3 machine, it appears like this:

Why is it not respecting the icon specification? o.O It was doing all right yesterday, with the dark camera icon...

[N3WWN]

Hmmm... very odd.

Are you sure everything is building correctly and that you're in the right branch?

I just checked my local copy and everything is committed locally, there are no files which are not checked in, the most recent PR commit matches my most recent local commit and here's my screen:

If you don't exec OpenShot from the command line, please try that and add 2>&1 | egrep -v 'timeline::webview|project_data' to the command line. For me, that makes my command line python3 ./src/launch.py 2>&1 | egrep -v 'timeline::webview|project_data'. This will minimize the verbosity of the output some so you can scan through what is left to see if there are any issues with the camera-photo-symbolic.svg file on your system or anything else.

I think what is happening is that it can't load that svg file and uses a system default.

I just thought if someone would want to export multiple frames and would want to ffmpeg them all?

Oh, you mean like Export Video -> Advanced -> Export To -> Image Sequence ? 😉

However, for the first frame, it defaults to the home directory - even for a saved project.

I'm unable to replicate this... based on the other issues that you're having, you may not have a complete checkout of the current PR. I'd be willing to bet a beer that your local checkout is at a39e6cf while the path retention was fixed at d95336c and the icon was included at c1b0401 . All three were pushed yesterday, but the latter two commits were submitted after the first.

[peanutbutterandcrackers]

I just checked this on my friend's 32 bit LXLE machine and it works really well. (And yes, OpenShot 2.x does have an i386 version. Awesome, right?) Just as it is supposed to work.

Maybe that is the reason. I'll test this out on the same Linux Mint 18.3 machine once my friend comes around (I've been testing things out on a few of my friends' linux machines - different distros to test out on).

I think this looks great!

I will try to test this again on the same Linux Mint 18.3 machine and get back.

Great work, good sir! 👍 You're awesome! 🏆

[peanutbutterandcrackers]

So, I am on my friend's Linux Mint 18.3 machine, again. And the same problem persists. And, I can confirm that I am in the right branch and that the said branch is completely in sync with your latest changes.c1b0401 is, indeed, the latest commit on this particular branch. And yet, for some reason, it is not respecting the icon specification.

I have attached the raw output (stdout and stderr all in a single file). Hope that'll help you in the detective work. I don't see anything related to the svg file, though.

log.txt

Also, I think this sort of window for screen-grab would be pretty neat too. It'd show the image, and is quite succinct. Just something I thought I'd share with you. :)

[ferdnyc]

Is this...

supposed to look like that? I haven't been following all of this, but it doesn't seem to me that the problems there are confined to just the camera icon.

camera-photo-symbolic is a standard theme icon name, which means that if that icon is available in the current theme, OpenShot will use whatever the theme icon is, and ignore the icon file in the source. That's by design, to give the application a more native look and respect symbolic differences between the iconography (heh) of different platforms/themes.

[peanutbutterandcrackers]

I don't know. For some reason it does look like that on this Linux Mint 18.3 machine. I even installed humanity-icon-theme package to no avail.

Also, if that is so, perhaps we should change the name to be something unique so that only the icon we have specified ourselves will be rendered? The symbolic icon matches really well with the rest of OpenShot. Not the one that Mint is currently using for some reason.

[ferdnyc]

I don't know. For some reason it does look like that on this Linux Mint 18.3 machine. I even installed humanity-icon-theme package to no avail.

Simply installing a theme won't do anything, by itself. Your desktop session will only use icons from the current icon theme. Installing a new one just adds to the list of themes available for selection.

gnome-tweak-tool (gnome-tweaks as of Gnome 3.28) has selectors for Application (decorations), Cursor, and Icon themes under its Appearance tab. That's where I'd start, because there's clearly something unhappy about your currently-selected icon theme.

Also, if that is so, perhaps we should change the name to be something unique so that only the icon we have specified ourselves will be rendered? The symbolic icon matches really well with the rest of OpenShot. Not the one that Mint is currently using for some reason.

Newwwp. We should absolutely not override the user's theme to force icon selection. That's one of those "fixes things on some systems with a broken local setup, but messes things up for lots of other people who weren't having any problems before" things. If wrong icons are being displayed because of a local theme problem, the local theme problem should be fixed.

This is the way OpenShot's preview window looks on Fedora for this branch, when running natively (not in an AppImage):

And that's the way it should look, using the icons from Fedora's default Adwaita theme. There's no reason to impose the Humanity symbolic camera icon. Yes, it's only slightly different, in this case, but there are many other OpenShot icons which are radically different between Humanity and Adwaita. And I'm going to assume that some other OSes — say, MacOS — may have camera-photo-symbolic icons that are very, very different from both Humanity and Adwaita. Imposing the Humanity icon in place of those would be extremely jarring, and could clash terribly with the local theme.

Fix your local icon theme, and the icons will look right. In fact, I suspect it'll improve things in a lot more places than just OpenShot.

In addition to the selector in the Tweak Tool, there's also an application gtk3-icon-browser — on Fedora it's part of the gtk3-devel package. That lets you browse through all of the icons in the current icon theme, both full-color and symbolic versions, to see what images will be provided to applications requesting theme icons. That can help determine whether things are kosher with the currently-selected theme.

All of this should be modifiable on the fly, but as always the Prime Directive for configuration changes applies: When in doubt, reboot — or at least log out and log back in again, as that should be sufficient.

[peanutbutterandcrackers]

Uff. Silly me. I did change the icon theme (from Linux Mint's Appearance Preferences) and it works rather well. All I had to do was change the theme.

Thank you for your help, good sir! tips top hat :)

[peanutbutterandcrackers]

@N3WWN - So, basically, it'll all great, good sir. Except, if you can, I think if the dialogue box of the screengrab pop-up looked more like the screenshot attached in my previous comment, it'd be even better. But that's just extra functionality now. I think this PR is good to be merged. 👍

Thank you for making OpenShot better!

[N3WWN]

Thanks @peanutbutterandcrackers and @ferdnyc for testing this and looking into the issues! 😁

I think the AppImage has a bunch of broken icons, too, as I have 44 icon warnings when I launch OpenShot.

Here's one of them:

ui_util:WARNING Icon theme media-playback-start not found. Will use backup icon.

I think fixing the icons across the board should be part of a different issue/PR.

[DylanC]

@ferdnyc Should this PR be targeting the develop branch now?

[ferdnyc]

@ferdnyc Should this PR be targeting the develop branch now?

Answered in this comment. (Short-short version: "Yes.")

[ferdnyc]

Ooh, I just noticed... if you're updating the src/images/openshot.qrc file, there's one more step necessary. That file is compiled into a binary format by a utility called pyrcc (Actually pyrcc5 for PyQt5), which is what's read by OpenShot. So, as src/images/README notes, you need to run the following command from that directory:

pyrcc5 openshot.qrc -o openshot_rc.py

And then you should check in the updates to openshot_rc.py as well.

[N3WWN]

Thanks! Done! 😁

[ferdnyc]

It's a terribly minor nit, but I'd change this to "right-aligned" instead of "right-justified", because to "justify" in the printing sense means "to line up evenly" — in other words, "right-justified" text isn't necessarily text that's slid all the way over to the right, but rather it's text that forms an even vertical right margin, as opposed to normal left-justified text which has a ragged right margin. You can't really "justify" a single horizontal line of icons, or anything.

Of course, you could claim that the exact same constraints apply to the word "aligned", and I'd be forced to admit that you've got me there, so feel free to just ignore me and I'll shut up.

[N3WWN]

I have no particular argument either way, so I'm good with making the change. 😜

[ferdnyc]

When running from the AppImage, OpenShot is sandboxed and doesn't have access to the system theme icons, so all of the icons come from the fallback set. There's no reason that information needs to be logged, it's effectively just a leftover debug printf().

My PR #1772 will (eventually) whack those icon-fallback messages. In fact they were one of my primary motivators for doing it, and the very first message I removed.

[N3WWN]

Thanks @ferdnyc ! I'll hopefully get the items that you brought up addressed before the weekend (which is when @DylanC will hopefully see this PR rebased to the develop branch, too!)

[peanutbutterandcrackers]

I wonder if 2.4.2.x bugfix series should incorporate feature PRs that introduce new (translate-able) strings. But since this is a rather small feature, perhaps we could send out another call for translation and add this in the bugfix release?

Maybe we should append an 'a' or something to identify bug-fix releases that ship with some new feature. 2.4.2.1a, perhaps?

I'd really like some inputs from the BDFL @jonoomph though.

I think, because of my comment, I should probably make my OpenShot Roadmap Proposal open to you all current core devs. Please do feel free to comment on the gist if you have some revisions/suggestions/criticisms etc.

[ferdnyc]

Honestly, I think at some point new strings have to go into the code, so that they're available to be translated. Translators work off of a list of translatable strings present in the source, so it's sort of a catch-22.

Don't get me wrong, in the run-up to a release I definitely understand the need not to introduce any new translatable elements. But post-release, the earlier new strings go in, the more opportunity there is to get them translated.

Now, that being said, it's probably a very good idea if we have some procedure defined for (a) tracking and (b) announcing the addition of new strings that require translation into the code, since presumably there are translators who could be informed of those events and asked if they'd very kindly help out with the needed translations. I mean, some of this is assumptions on my part, I really don't know how the process of getting OpenShot translated functions, from a practical standpoint. @jonoomph is definitely the expert we need on that front.

But I'd suggest, for starters, creating a tag that gets applied to any PR that adds or modifies translatable strings in the code, since merging those PRs should be treated as a Bigger Deal than merging any other sort of code change.

[N3WWN]

Closing this PR against OpenShot:master in order to submit a new one against OpenShot:develop