Re: [Kdenlive-devel] a few issues

[Jason W. <jas...@bl...>]

On Thursday 09 Jan 2003 3:36 pm, Rolf Dubitzky wrote:
> Hi all,
>
> here is another list with minor things I noticed. They are in no particular
> order, some are just little bugs, some should be discussed. (I'll put it on
> the web todo-list, so we can keep track what needs to bo done)
>
> minor
> =====
>
> - kdenlive starts up with a single frame timeline. Why? Is it not possible
> to have an empty timeline?

It was an easy way around some divide-by-zero issues. Now that the little 
things are being considered important, I'll see what I can do about it.

> - the slider marker points always _between_ frames and kdenlive requests
> the frame _after_ the marker to be displayed, but it is possible to move
> the slider beyond the last frame.

Ok, so the project length essentially needs to be considered to be from 0 to 
totalLength - 1.

>
> - Even better would be to make the slider cursor not a line, but a bar with
> the width of a frame. (and just xor'ing whats beneeth) In MovieDV the
> marker is just two lines connected by a bar on the top (one before and one
> after the current frame).

This makes sense when the zoom leve allows you to see individual frames, but 
what about if you are working at much higher zoom levels?

> - open recent, does still not work for me

A known issue, and I'm not sure what is causing it - essentially, the open 
recent does display recent projects, but when it calls the relevant kdenlive 
method telling me to open it, I get sent an empty url. I will have to look 
into it.

> - the 'selection' and 'clip' inputlines. I think it looks rather strange to
>   have them, but don't do anything. Either get rid of them, or display
>   something, maybe duration/in/oupoint of the current clip. If they stay,
> and are in priciple readonly, they should _really_ be readonly.

Ok, I'll remove them for the moment - the edit panel will get a redesign very 
soon anyway.

> - 'play' button. They play button should stay pushed down as long as the
> video is playing, be released when it stopped.

This, along with the marker moving automatically during playback, will happen 
as soon as the play status commands that you mentioned previously have been 
implemented. It should be very straight forward, but if I do it at the 
moment, the play button will just get stuck down :-)

> - I think we need a 'View' menu, where you can checkbox which windows you
> want to see, because if I delete one of the DockWidgets, it's gone, and I
> don't get it back. Actually I don't think we should allow to delete these
> windows. It doesn't make any sense to delete them.

Agreed, a view menu is needed. I do not particularly want to stop people from 
deleting the widgets if there is a way to bring them back, because it does 
allow for people to construct their own dedicated "modes" of operation if 
that is what they really want to do.

And in some cases, it will make sense - for instance, if kdenlive is being 
used with a renderer which doesn't have transition/effect support, the user 
would probably want to get rid of the transition/effects windows simply 
because they are redundant (yes, I am talking about functionality here that 
kdenlive does not yet have anyway...)

> - "New Window" will not work with piave. So either disable it when using
>   piave, or delete it.

Ok, done.

Incidentally, does piave have a fallback to normal screen usage if xv fails or 
isn't wanted? I can think of two reasons why I would like this :

1. It makes the screenshots look better (with xv, you just get a blue window 
where the video is being overlayed)

2. I have at least one UI design concept that I want to implement in the 
distant future which will require many monitor views on screen at once - at 
that point, speed for me won't be as important as testing the theory of if 
the UI works or not.

> - "Export timeline" ... I would rather call it "render project" or "render
>   timeline"  ... with "export" I think of 'saving in a foreign format',
> e.g. SMIL.  Also there could be a "render selection"

I have no real preference. What do other people on the list think?

> major
> =====
>
> - monitor window; we talked about that a bit already.
<snip>

Ok,. there are two main issues here :

1. The monitor has no features implemented at the moment other than playback, 
and needs them.

2. With the timeline, there is no feedback whilst resizing and cutting clips. 
This problem is because we are not sending the scenelist on every resize, but 
will suddenly be a trivial matter to solve once we have a "clip" monitor 
(since we will just tell paive to seek to the frame we are resizing to).

However, I think that implementing the monitors will take a more than just a 
weekends work - I might be wrong, by I tend to underestimate time rather than 
overestimate.

I think that we should go ahead with a beta release sometime this week with 
what we have, and then aim for V0.2

I was hoping to start on transition/effects, but I think that it does make 
more sense to get the monitor support and editing tools in better shape 
first, so I think we should aim for the following list as minimum for V0.2 :

Version 0.2
* Monitor has editing capabilities
* Piave shows resize operations whilst they are in action
* Improved editing tools via the timeline.

What do you think?

Cheers,
Jason

-- 
Jason Wood
Homepage : www.uchian.pwp.blueyonder.co.uk