On Thu, Oct 24, 2002 at 09:58:15PM +0200, Charles Yates wrote:
> On Thu, 2002-10-24 at 20:35, The Surprises wrote:
> > Hi, here are my 2.5 cents on the GUI redesign effort. If we look at
> > what a 'typical' user wants in an editor: he/she has a set of footage,
> > probably all taken from a single camera.
> For many people, the requirements stop here. For a large majority of
> users, all they want to do is remove adverts^H^H^H^H^H^H^Hunwanted
> footage and convert to mpeg/divx - these people are the easiest to
Hmm. You're definitely right here, and current Kino works very well for
this without any need for a timeline..
> > He will have a main video
> > track where he will mainly want to put transitions/effects between
> > scenes.
> For many people, it stops here.
> > He will also want to have a separate audio track for
> > background music. Optionally he will also want a 'title' track where
> > he will want to easily overlay titles.
> > The more advanced user will want to do constant audio volume matching of
> > disparate scenes. He will probably have another audio track for sound
> > effects. He will want to sync up various actions in the main video with
> > the sound track, so a view of the waveform would be necessary. He will
> > probably want another couple video tracks to do interesting things like
> > video overlay, blue screen effects, custom gradient alpha channel
> > overlays..
> OK - the point I'm trying to make is that some people simply don't want
> the clutter or the bloat of a fancy set of functionality, especially if
> that clutter makes their immediate requirements seem inaccessible. I
> feel a multi-layered timeline shoved in your face and requiring
> attention is a turn off to the first two types of users (and I would
> imagine that many of our users fall into this category if only by dint
> of the fact that that is pretty much all we provide :-)).
> In my view, a timeline is one of many views that are valid when tackling
> video editing - there is simply no magic bullet that satisfies all
> > Whether you're a typical user or more advanced, you will have a bunch of
> > things happening concurrently, and in my opinion the multitrack timeline
> > editor is the only place where you can 'visualize' what's happening in
> > your design. Admittedly, you can probably do everything you want with
> > the current FX flow, but I feel that the current approach becomes
> > unmanageable for complex designs. It feels too 'all or none.' Once you
> > create an FX, it's rendered and in your playlist. There's no history of
> > the FXs you performed. It's difficult to quickly do what-if analyses or
> > change around your ideas. You also shouldn't have to use the FX flow to
> > do the most used tasks like volume control on audio and maybe fader
> > control on video.
> Just to set the record straight, the current FX implementation was never
> meant to be a *good* solution - it was a quick hack that got adopted in
> kino to provide some very basic functionality (I will admit that the
> quick hack took much longer than I had anticipated - time that probably
> would have been better spent on doing it correctly, but, what the hell,
> I think the results are kind of fun ;-)).
> The idea is that Dan's new DOM will take care of the editing
> requirements (by essentially serialising the FX configuration into the
> SMIL document) and potentially, we will be able to provide lazy
> evaluation from there thus removing the render *requirement* [but not
> the functionality].
> Up to now, our concentration has been on ieee1394 integration and
> simple, but essential, functionality such as the SMIL implementation,
> reliable playback, copy/cut/paste and trim and so on. Only recently did
> libdv start exposing an interface for encoding, so that particular
> functionality has only been available to us for a few months (there was
> simply no point in even considering a multi-layered timeline until that
> functionality came on board).
> > So I kinda disagree with Charles and feel that the timeline is perhaps
> > the most important function and should be readily available instead of
> > under one of kino's pages. I think the user will spend most of his time
> > here.
> The way I see it, whether the timeline is the default presentation
> shouldn't present an issue at all... at most, it'll be one click or key
> press away.
> The timeline workspace can carry its own preview window and provide a
> full complement of functionality - what I definitely want to retain is
> the current Editor, which is a keyboard driven, friendly, sensible and
> covers the requirements of many of our users.
> In relation to the other responses on this thread, maybe we could even
> have a way of reorganising the workspaces so that you can select your
> own default? Dunno - hardly seems like an issue to me.
I also like the editor. It's a very nice interface for working with
individual clips. I also agree that this should remain. This could be
where you edit all of your clips, cutting, pasting, arranging, video
effects. Then you could drag the clips into the timeline, or you could
push a button and snarf the whole thing into the timeline for further
> > Hence, I started to write one! I've written several GUIs, but this is
> > the first GTK+ one. Regarding the global widget structure, I'll admit
> > that I cringed when I took a first look at the Kino widget architecture.
> Heh - no surprise there. When I came on board, I took the original
> design of the app as my introduction to gtk/glade et al, and failed to
> see how glade could be used to make more refined widgets. Hence I
> settled for the activation/deactivation of the 'global' widgets as at
> least it would avoid the issues of duplicating parts of the GUI
> throughout the applications window. This was not the best approach, but
> it's served us OK up to now... the first task I want to resolve in the
> re-design is removing these global widgets, and replacing them with
> multiply occurring objects.
> > The way I've written GUIs in the past is to have each component of the
> > design own it's widgets, so the global nature of the Kino widgets was
> > different to me. However, I decided to mirror the Kino architecture for the
> > timeline design so that it could hopfully be placed into Kino more
> > easily. So, I ramped up on GTK and glade. One of the things I like
> > about this style now is that you decouple the GUI development with the real
> > content of the design. This allows you to iterate on the GUI looks
> > without having to touch the other code. I've made wholesale changes to
> > the timeline GUI over the past few weeks to get it just right. It would
> > have been more difficult to do if each section of the timeline owned
> > it's widgets. We do lose the ability to create multiple widgets, but if
> > the widgets have no reason to be duplicated, then maybe it's not that
> > big of a deal.
> Well, I'd like to have a proper chance to review your code here. I've
> found a few ways to use glade to produce multiply occuring widgets, and
> my initial take on the demo you sent me was that it would fit right in
> there. The main thing to do is simply not use glades built-in callback
> mechanism (as it doesn't provide a very clean way of associating events
> to the instance of a widget - short of using a bunch of nasty globals
Seems like all signs point to gtkmm. I just took a look at it and it
gives the same look and feel as QT, which is good for me :)
> > Regardings libsigc++ and gtkmm. I also don't like the event mechanism
> > of GTK+. I'm doing the static to c++ method callback workaround in the
> > timeline and don't like it. libsigc++ seems to fix this. I have
> > written a couple GUIs using the QT GUI toolkit (www.trolltech.com),
> > which is a full c++ GUI package. I really liked it. They also have a
> > very nice signal/slot event mechanism that I thought was very intuitive.
> At one point I was all in favour of QT, but after getting to grips with
> the way the GTK+ environment works, I must admit that QT has totally
> lost its appeal (but then, knowing what I do about the GTK+ environment,
> being exposed to QT again would probably make me switch back :-)). For
> now though, I'll just point you to my reply to Tim's mail this
> Anyway, many thanks for your input, and please let me know when you have
> a new timeline demo which I can play with :-).
I have made a few more enhancements to the timeline. You can add
transiiton tracks. Transition tracks have the unique ability to be
resized, which isn't available to the other tracks. I've also snarfed
the custom hruler from Ardour which creates a time based hruler instead
of just a set of numbers representing the frame. It gives you a better
idea of where you are in the timeline. I don't quite like how it was
implemented - the ruler ticks don't move, only the numbers change. It's
kind of awkard to look at when you're scrolling. Ah well, maybe I'll
back out of it.
I can send you what I currently have. It's currently in a state of flux
because I'm trying to implement drag-n-drop of clips to other tracks,
but I can patch it up and send you something working.