[Kdenlive-devel] UI

[Jason Wood]

On Tuesday 18 Jun 2002 11:09 am, Christian Berger wrote:
> Jason Wood schrieb:
> > Ok, let's try again now....
> >
> > My current plan for how a project holds clips is as follows.
> >
> > A clip can consist of simply a video file, or an audio file. It can also
> > consist of both, which would be what you would expect with video which
> > contains audio. The user can of course specify if they only want the
> > audio or video of a clip for a particular purpose.
>
> Makes sense. You might also have a posibility to "link" clips together,
> so if you move one clip in time, or crop it, the other clips get moved
> and cropped, too. 

agreed

>				(but cropping should also be done individually, for
> example enabling it to crop the video, but not the audio).

I think this depends on what you are trying to do - if you have several linked 
clips which you want to be able to move around together, then it may make 
sense to be able to crop them individually, whilst if you have a single clip 
which has both video and audio, most of the time you will want to crop both 
simultaneously.

I think we can consider there to be three levels of linkage :

- Behave as a Clip - for all intents and purposes, the clips which have been 
linked together are treated as a single clip. New effects can be applied to 
the "clip", it can be cropped, moved, speeded up, slowed down, etc. The 
elements within the clip cannot be moved, but they don't actually change 
either.

- Behave like linked clips - the clips are linked together but are still 
individual. By default, all linked clips are moved as a single entity, but 
this can be overridden without breaking the link (for "tweaking"). Other 
effects, such as adding blur, fading, etc. only apply to the clip being 
worked on, but this can be overridden.

- Individual clips - the clip has no relation to any other clip.

> Of course clips also should be able to be parts of files, so you can
> just record your footage to a single file and then edit that.

A clip will basically contains either another clip or a file, which has start 
and end points set, so there is no problem with this. The fact that we can 
crop clips dictates that this has to occur.


> Well how about something like this: Hirarchical groups. So it might look
> like this:
>
> Title group:
>   Title project (group in another file project file)
>     clip1, clip2, etc
>   credits (individually for each episode)
> clip3
> clip4
>
> Maybe the smallest group should be audio and video from a clip, then you
> may make larger groups out of it, forming scenes and things. The project
> is the largest group. Every group should have "parameters" which are
> global inside the group. Every parameter should have a name and a value
> and should be set to "fixed value", "nothing" and "parameter of the
> parent group". All clips and effects also should have paramters for
> everything which can be set (including filename and start/endtime
> althought we probably will only use those rarely).
>
> Imagine the following situation. You produce the pilot of a show, but
> aren't sure of the name or the logo yet. You can simply create 2
> parameters of your project (group), one named title, the other named
> logo. Then everywhere you want to have a title you enter a clip with the
> logo as a parameter (maybe filename), you can aditionally pass the tile.
> So if your logo is another project, it could have the text property of
> the text effect as a parameter and therefore take the title from your
> project.
> So you can render the whole thing with different titles and different
> logos, by only changing the parameters. Just think of corporate
> idenntities of companies, they could just change their basic logo which
> contains a title placeholder and you just have to change the "logo
> project" to change the logos inside all shows using it.
>
> For the parameters I'd suggest the following internal structure:
>   type:int (says wether it's a fixed value, nothing or the parameter of
> the parent group and how the user interface should look like)
>   value:string or variant (contains either the value, nothing, or a
> string saying something like "parent.title", we might extend it to use
> forth at some time in order to efficiently and simply do things like
> internationalisation)

If I get what you mean, I think it can be summed up in one word - templates 
:-)

The problem that comes with a lot of the parameters is choosing which ones 
should be made available to the user to change - if there are a lot of them, 
then it defeats the point of having templates.

I think, thought we could get around this if the user can, whilst putting 
together a template, right click on a clip and have an option "add 
parameter->list of parameters", which would then get added to the templates 
"properties". When a template has been built, it can be saved for future use.

I think a very useful addition to this would be a clip as a parameter (rather 
than a filename, a clip is more generic). For example, there is a series 
being made, and the title sequence only has different names, the end credits 
only have different names, and then the show goes in the middle.

You could make a template for the show, which would have the following clips 
in order :

The title sequence template, which exports "Name of episode",  etc.
A "template clip", which is there to be filled in
The End Credits, which exports the "credits" parameter.

With this template clip saved, the editor of a show would simply :

1. edit the show together.
2. Link it al together into one big clip
3. Create a new "Template for show" clip
4. Drag the edited show to the "template clip" parameter, fill in the title 
sequence, etc. and everything is done.

Whether this is actually easier than just moving the show clip and putting the 
title sequence clip template at the beginning and the end credits template at 
the end is debatable of course.

Cheers,
Jason