[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