[Kdenlive-devel] Finally, a few keyboard shortcuts.

Rolf Dubitzky R.Dubitzky at Physik.Tu-Dresden.de
Fri May 9 08:19:01 UTC 2003


On Wednesday 07 May 2003 22:33, Reinhard Amersberger wrote:
> > No, we don't need an "overwrite" mode. You just drack the clip to the
> > timeline, and the clip will only attach to a empty track. "Overwrite" is
> > a redundant operation for an editor with infinit number of video tracks.
> > It just adds to the confusion.
>
> But this will result a_lot_of_tracks, which also adds to the confusion in
> my opinion. Think about an music video where sometimes you have a new scene
> every second ....

Hmm.. I don't think so. maybe we are talking about different things here. 
Right now in kdenlive as it is, you can already put together a project where 
you have a new scene every _frame_ and you only need _one_ track. where is 
the problem?

> Apropos transition......
> How do you like to do it?
>
> I would prefer to do it just like audio tools.
> I mean user simply overlap two clips in the same track to create a
> automatic dissolve (called "crossfade" for audio). Same for fade-in,
> fade-out .... just move the upper left corner to right to create a fade in
> ...

That is not possible, since "transition" will probably mean an arbitrary 
operation which involves two video tracks. so I think we have to insert 
something like effect tracks, which relate two video tracks. But Jason has 
probably more to say to that.


> Why providing a special GUI for capturing?
> It is very unconfortable in my opinion to open another application just  to
> capture new material that is needed for the already opened project.

You think windows. Think KDE. The user will not be able to tell what part of 
kdenlive is in a single binary, in a separate application or KPart etc... 
Also, it doesn't matter much from point of view of programming. Maybe it adds 
some flexibility. If not, it will just be a GUI element in kdenlive. It realy 
doesn't matter in the end I think.

> SURE!!!!
> It wasn't my intention to drop menu-bars, buttons, check boxes and so on
> ..... The goal could be to have a fully customizable GUI where users are
> able to enable or disable and move around all of such components, similar
> to the layout concept.

I think so. judging from the current design of kdenlive, I have no doubt that 
this will be pretty configurable in the end ;-)

> As far as I understand correctly I would say yes, because the goal is that
> the user have the choise to use his favority way of editing ... or use a
> combination of both.

Hmm, maybe I try to rephrase my point. I'm an emacs user, thus, I hate emacs. 
I like keyboard-shortcuts. There are two types of shortcuts. A) a shirtcut 
that represents a menubar-entry/function/checkbox/button and is by that means 
directly integrated (i.e. visible) in the GUI, and as a such 
self-documenting. B) shortcuts that don't appear in the GUI, only in a 
documentation/help/guide.
Emacs used to be made of type B keyboard commands. Only recently and in XEmacs 
there are some commands also appearing in the menubars. Type B _requires_ the 
user to read external documentaion which is usually not available or worse 
not up to date, hence, type B sucks. ... in my opinion   ;-)

Actually, I think you question about the transition thing is much more 
interesting and important. That might be really difficult.....???? 

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky          http://hep.phy.tu-dresden.de/~dubitzky
 e-mail:         Rolf.Dubitzky at Physik dot TU-Dresden dot de
***************************************************************






More information about the Kdenlive mailing list