[Kdenlive-devel] UI

[Christian Berger]

Jason Wood schrieb:
> 
> On Tuesday 18 Jun 2002 11:09 am, Christian Berger wrote:
> > Jason Wood schrieb:
> >                               (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.

Well I'd do it like this, if one clip gets moved croped or anything,
this is applied to all the other linked clips relatively. So if one clip
gets moved by 1 second the others get, too. Now if you press a special
key, you can move/crop one clip individually, but it still stays linked
so it can still be moved together with the others. The key is to see all
those operations relative and not absolute.
 
> > 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.

True, didn't think of that.
 
> > 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.

No, those parameters will be defined by the users, they are like a row
of terminals, you can put values on each of them, and every effect
(which has it's own set of user accessable parameters) can "connect" to
them. So, imagine the text effect. It's text value is set to
"parent.title". The text effect could be in the logo group, so
parent.title refers to the "title" variable of that group. That
variable/parameter was defined by the user and could have virtually any
name. Maybe we could also add some "global" parameters like
"global.date" or "global.companyname".
 
> 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.

Preety much. Have you ever seen Corel Draw? Their group thingy is nice,
but we should add a "save-group" option. As well as a function to read
groups from files, but only link to the files, not actually copying the
content.
 
> 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.

Ohh yes, that's good, so a filename, startpoint endpoint and maybe other
parameters. as well as another project as a clip.

> 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.

Hmm, how about this, every effect/clip/etc does have parameters and can
be set to "take the value from the project", now if projects can also be
imported as clips, the problem is saved.

Now, if you have the show project and the opening title project as well
as the credits project. Both the opening title project as well as the
credits project have parameters. (maybe even the show itself). Now you
also have a "completely" project containing the 3 other projects and
having parameters for the show-clip, the title of the show as well as
"special guests" or somethign. When done correctly, you could just use a
shell script to "batch-cut" shows with the procect/cutlist converter.

 
> Cheers,
> Jason

Servus
  Casandro