[Kdenlive-devel] relative paths in project files

[Mads Bondo Dydensborg]

fredag 14 November 2008 skrev Dan Dennedy:

> 
> > Could you explain briefly what would be the use of the relative path 
feature ?
> 
> Move the folder containing the project file and all of its assets to
> another place or move it shared storage so I can access it from
> another system that might have it mounted at a different location.
> 
> I do not think there is a universal solution.

Probably not. However, I couldn't help thinking about the way kphotoalbum does 
it (http://www.kphotoalbum.org/): 

------
http://wiki.kde.org/tiki-index.php?page=KPhotoAlbum+FAQ#Can_I_move_my_images_around_on_disk_

Yes, since version 1.1 KimDaBa now stores check sums for each image. Before 
moving images around, you might want to invoke Maintenance|Recalculate 
Checksum - this should, however, only be needed if you have modified your 
images (removed red eyes for example) (contributed by: Jesper Pedersen, 
UserPageblackie)
------

This might be inspirational? What kphotoalbum appears to do, is to scan all 
files below a certain path, and match against the size/md5 sum database that 
it has. This is very quick - it scans my image collection of about 18000 high 
resolution images in 20-30 seconds. If I should move things around, it would 
be slower, of course. Again, for inspiration: If we stored md5 sums of clips 
with other metadata in the project file, we could offer the user to search (a 
path/tree) for a clip, if it was missing. That way, you could move all your 
stuff somewhere else, open the project file, and have kdenlive look up all 
the clips again. Or something.

Another thing KPhotoAlbum does (or at least did once) is that it allows image 
collections on cdroms/moveable media that are not mounted to be "used": that 
is, it is still searchable, and so on. It just appears with a "placeholder" 
icon in the GUI. In Kdenlive that would amount to e.g. being able to move 
clips around in the timeline, edit titles, all that kind of stuff, without 
having access to the actual clips on disk at the moment. Of course, it would 
not work for render, even though one could envision a partial render of the 
available clips.

Regards

Mads

-- 
Mads Bondo Dydensborg   mads at dydensborg.dk   http://www.madsdydensborg.dk/

Who do you trust? Nobody? Good, let's put Nobody in charge then... 

               - The Register on TCPA/Palladium, 20021109