[Kdenlive-devel] UI

Christian Berger einStein at donau.de
Tue Jun 18 10:09:02 UTC 2002


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. (but cropping should also be done individually, for
example enabling it to crop the video, but not the audio).
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.


> By having clips as containers which can potentially hold an entire project, we
> could simply import the entire title sequence project into our project, and
> handle it as a single clip. If we need to then modify the title sequence, we
> would "expand" the clip somehow (I have yet to determine the best way to do
> this), which would allow the contents of the clip to be edited. Once that was
> finished, the clip could be "closed" again.
> 
> Why is this particularly different from editing the title sequence as a
> seperate project and rendering down to a single clip? Partly because it means
> that the user doesn't have to change focus - they are working on the main
> project, they merely double click the title sequence (or some other well
> defined command to "expand" it), modify it, and then go back to working on
> the original project. Partly because the title sequence "clip" can be
> modified seperately for each show, and will be stored in the relevant project
> file. Finally, the user does not need to remember project names on the disk,
> which quite often end up swamped in the .avi, .wav, etc. clips.
> 
> What do you think?

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)

What do you think?

Servus
  Casandro

> ----------------------------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                       >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Kdenlive-devel mailing list
> Kdenlive-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel




More information about the Kdenlive mailing list