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