0

When will we be able to have real "independent" links, that we can use a project in another folder.

Currently we have "hard links", if I move 1 character where my folder is kdenlive will tell me that a file is missing

in other software, like "synfig studio", or "inkscape"
if you link a file in your project, it is the link of the sub-folder that is added as:

/files

at kdenlive it's different it will be :
/home/login/videos/test1/project/files

so it's very problematic, I once had to rename my working folder, and then impossible to open the project, (there are many folders I can't move or rename)

here I submit the idea of being able to work with sub-folders like:

/files

instead of:
/home/login/videos/test1/project/files

thank you

I am confused by this ...
I do not know kdenlive, but looking at the examples you give I wonder whether you do know about the differences of relative and absolute paths ...

I did not find anything about relative and absolute paths in the preferences.

Well I don't understand, because I feel like I was wrong, please excuse me.

mistake I made so I spoke before checking
I have files with 2 to 5 GB PNG renderings

so i didn't copy paste elsewhere to open them at another location

because by chance, I copy paste a folder with at least 30 files.kdenlive
and 1 MP4 video, and it opens it to me in any partition.

Please excuse me, because the error telling me that the location of the file does not exist I have had it more than 50 times, (wrong naming of the source file, or I did not keep it).

Now I'm going to be careful to keep small mp4 files, name them well to be able to have an archive.

Happy Christmas to all kdenlive users.

So your suggestion is to phrase and encourage a general architectural decision to only use relative paths to refer to resources in the local file system in all applications.
That would also require an additional setting in all applications which defines the root folder inside the local file system from which those relative paths have to be interpreted, so something like a "project base folder" for each application.

The implementation has to occur in the applications itself, the KDE platform cannot somehow enforce such thing.

My approach (which I promoted some 15 years ago but gave up after a few years) was to discourage the use of a hierarchical file system as we know it in general. Because it actually causes a lot of headaches despite the fact that it appears as an intuitive approach at first. Unfortunately that only works for 90% of all use cases, the rest ends in situations as you describe it.
Instead I suggested to use a management system which internally stores resources in a file system just as it internally descides. I am actually not interested in that as a user. I want to access my resources based on different strategies instead of being forced into having to think in an inflexible hierarchical file system. That management system would allow me to access content by tags, by project, by type, by cross references, by timeline, by relevance, whatever, without me having to somehow try to code such information in file names or perform lengthy filterings and search runs on the file system. So you could think of such system as a "multidimensional file system". The management acts as a "butler" between the user and the technical storage solution. The backend storage solution can then be swapped, migrated, rearranged without the user noticing such changes.