A User Choice for A Limited Expansion Of Relative Paths

Give the user that choice, when creating a new project, of extending this one level up.
(In actual software, this would probably actually be pushing where the ,MLT files live one level down.)

The choice as presented to the user creating a new project; a checkbox.


I should have called it “Relative to Project Folder” or “Relative to Selected Folder.”

Just as now, clicking Start creates a new folder under the folder selected in “Projects folder”, just as now, the folder is where all .mlt files will be stored by default.
Any files dragged to the playlist from the folder named in “Project folder” will now be relative, as are the files in the newly created folder and below.
Just as now, any files dragged to the Playlist from elsewhere will have absolute paths.

This does NOT attempt to incorporate a user’s entire chosen file/folder organization into relativity, it only enables a user to choose to segregate .mlt files from video files, and have the video files at the higher level, while keeping the advantages of relative links within the project.

This is the exact opposite of how it works today. That’s fine and equally functional, but what’s the advantage? Since there are typically many more video files than .mlt files, wouldn’t it be more intuitive to create subfolders for video files (for categorization) and push video down a level rather than push .mlt down a level? I’m not trying to say this is a bad suggestion at all… I’m genuinely trying to understand what advantage comes from reversing the hierarchy.

This change would also require paths in the .mlt to be written as ../VideoFolder/VideoMedia.mp4 in order to get into parent and sibling folders, which is not supported today. It’s also kinda dangerous. (Unexpected following of symbolic links; files copied to the root of a flash drive where .. doesn’t exist anymore, etc)

Not true for me.
In my case, there are typically one to four videos, never more than eight, but twenty or thirty .mlt files, some of them a trail of “Ooops”" to go back in case I reach a dead end or find an early mistake, and some are because I have a branching path leading to several similar but different final files.

So everything I have is in a hierarchy of “My video files”, with Shotcut attached to each “for this final outcome” folder. Under that folder will be a folder for the local project unique branding, a folder (which I always name “Shotcut”) with the MLTs, and perhaps a folder or still image edit with The Gimp, or a folder of extracted audio with edits in another app.
This is the opposite to what is clear many others do, having a hierarchy of Shotcut projects as their folder structure.

There are actually more than the one to four videos in each Shotcut project; the others are stock (for me) branding files, and the way Shotcut handles these as absolute paths is GREAT!. Being able to reference them the same way no matter where I am means I can copy a “Shotcut” folder from one project into the videos folder of a new project, rename the “ProjectName_100.mlt” to “NewProject_100,mlt” and take off running. (This “,_100” MLT contains only the stock videos, by absolute path.) So for these stock files, absolute path is a lifesaver.

Interesting, but I was hoping to get more detail on specific advantages.

The number of video files is immaterial. If videos (regardless of number) were pushed down a level into a “Videos” subfolder, that leaves the root folder completely empty for the 30 .mlt files you wish to make. Isolation is the same. The workflow is identical either way. I was hoping to find a benefit that made the .mlt pushdown significantly better rather than just equal. If the benefit is as simple as a desire for a clean root folder, I could certainly understand that.

I am now experimenting with a folder created exactly according to the steps listed where I got the original quote; created Shotcut project, moved videos into folder, then from there to the playlist, and from the playlist to tracks.

One thing I found, symbolic links are ubiquitous, they are not a unique problem to the proposal.
I have three linked file on my playlist, in three levels of folders.

here is one in the MLT:

was here

Shotcut seems to be handling it perfectly.

I’ve been a software engineer for more than fifty years; the dot-dot symbology for the higher level came into vogue about ten years into my career. I have never seen such a one-level up-reference cause significant problems in well-written software, regardless of the environment,

I have listed the specific advantages - for me.

You have a different workflow, so these do not appear as advantages to you.

In pushing down the videos, you are asking me to reverse my hierarchy. This would be a distinct disadvantage for me.

The advantage summarized is that I would not have to exactly replicate the upper hierarchy to open a project; the local hierarchy will be maintained.

Specific case:
All of my work is in a folder on my “home” called “Projects”, this is currently, as is “home”, on sda1. The reason it is a folder, is that soon I hope to move “Projects” to a physically separate drive, where it will be on sdd1.
Hopefully, I will be able to make this invisible to to Shotcut using a symbolic link. (So I hope Shotcut has no problems with symbolic links.)
This kind of move would become seamless, without a symbolic link, under this proposal, without forcing the user to use a particular hierarchy for the organization of video files, subordinating the them to Shotcut projects.

Of course, one can solve the problem by doing it your way AND my way using circular symbolic links…

Fair enough, I can see that. I hope I’m not coming across as argumentative or unappreciative. I’m always on the lookout for ways to improve my workflow and get better results. If somebody is doing something different than me and can convince me their way is better, I will switch to their method that same afternoon! I just wanted to see if you were onto something I could incorporate.

Totally separate side note… For me, this is the gigantic deal-breaker to absolute paths. Moving files around can potentially break projects. I’ve outgrown and migrated through enough hard drives and computers that trying to remember the stock media and inter-project dependencies of old projects would be impossible at this point. The symbolic links to Band-Aid it would be a maze of spider webs that nobody wants to debug (or replicate when buying a new computer). Likewise, absolute paths and symbolic links don’t translate well if multiple computers are editing video stored on a central NAS. Thus, I have to use entirely relative-path localized-copy media for my sanity’s sake. All-relative media also makes it super simple to do dependency-free archival to reclaim disk space, and to transfer projects to an external drive for a collaborator to work on. A collaborator would not be able to open your current projects unless they had the exact same stock folders that you do on the exact same mount points. Similarly, if your stock media hard drive is different than your project drive, and if the stock drive ever failed and you were unable to rebuild it exactly the same, then old projects would be broken in that way too. Absolute paths are certainly fine for a single user, or for someone that doesn’t care to reopen old projects. But I can vouch that absolute paths don’t scale beyond that, as I’ve learned the hard way. For extreme clarity, I am not saying anything bad about your methods because they do work for your use case. I’m simply explaining why I changed from those methods as my projects grew larger.

For projects done as a series, meaning multiple projects that all have the same 10-second intro clip in them, I create a “Template” folder with the intro video already in it, then copy “Template” to start a new project rather than start from scratch.

I occasionally like to sleep. When I wake up, I don’t remember how stuff like this was configured. And then I lose half a day trying to reverse-engineer it. I can’t afford to do that anymore. :rofl: But I congratulate your engineering skills.

I wouldn’t expect anyone to change their workflow because this is available; rather, it was thought of as a way to integrate Shotcut into a person’s existing workflow and file hierarchy.

The circularity was a humorous (and potentially dangerous) side effect of the thought-experiment of making the Shotcut folder subordinate to the video folder while preserving relative references.

All of my attempts to construct a local-copy-then-archive system have sadly run into budget walls over the years (I never can afford enough storage space). In theory, though, I agree that is the most robust system.

You have stimulated my thinking. @Austin . I have come up with an alternate proposal:

It has two parts…

Move the choice of upward relative links to a place in “Settings” where only advanced users will find it; make it a choice of how many levels upward (with their children) will be relative. Default=0.

Create a new optional window “Resources”.
The purpose is for files such as branding and stock footage, or mask collections.
In it, the user can create one or more named absolute paths, These can be clicked on, to select files to add to the Playlist. Shotcut will store the name-path mapping in the MLT file.
If, upon opening a project MLT, these folders do not exist, the user is prompted the same as now for finding lost files. If that is bypassed with “OK”, these can be remapped from within the project.

Saving an MLT with no Resources but an empty Playlist creates a workspace template.
Saving one with Resource files in the Playlist creates a project template.

Normally there is no remapping, but when retrieving a three-year-old project, the remapping is structured and thus simpler than otherwise.