[Kdenlive-devel] Inpoints/outpoints, problem I need to tackle.

[Jason Wood]

On Friday 18 Jul 2003 10:21 am, Rolf Dubitzky wrote:
> On Thursday 17 July 2003 10:38, Jason Wood wrote:
> > It's this last step that's tricky :-)
> >
> > The problem stems from the fact that kdenlive does not receive mouse and
> > keyboard clicks that occur on the area of the screen owned by piave.
>
> I while ago on IRC #KDE some guys chatted about that I think tere is a
> trick you can do to get the events, but I am not sure if I remember
> correctly, and if so, I don't know the trick. Did you ask around a little?

I have now, and I like X more than ever :-)

Every window in X has an event_mask and a do_not_propagate_mask, which 
together say which events a window will handle, and of those it doesn't 
handle, which get propagated to it's parent.

It's a one liner to set these so that piave ignores all keyboard/mouse events 
and passes them directly to whatever application it happens to be embedded in 
- oh look, it's kdenlive ;-)

I've made the change on my local copy of piave, and it works almost perfectly 
- I do get the following error when I try to use the mousewheel over the 
piave window for a period of time - I have removed the mousewheel event code 
from piave, and handle it via kdenlive and VEML seek commands. The error I 
get is this :

Xlib: unexpected async reply (sequence 0x157)!

(with varying values for sequence)

I have looked the error message up, and it appears to mean that there is a 
multithreading issue going on - I am not sure if this is an issue with one 
app being embedded in the other, or if there is some subtle multithreading 
issue in piave that is only being brought to light by lot's of veml commands 
being sent one after another, I'm still exploring the issue.

> > I have a few thoughts on how to solve this :
> >
> > Idea 1 : Make the piave window ignore keyboard/mouse events and pass them
> > directly on to whatever window it is embedded in (i.e., let X take the
> > strain of getting the events to the right place).
>
> I don't understand. Would that mean that piave needs to actively pass all X
> events to kdenlive? Anyway, I like this way much better than Idea 2.

See above - no, piave simply has to say "I don't want to handle keyboard and 
mouse events, please pass them to my parent window". The change I have made 
is quite literally a one liner :-)

XSelectInput( _sysWMinfo.info.x11.display, _sysWMinfo.info.x11.window, 
ExposureMask);

This resets the event_mask on piave's window so that it only responds to 
Exposure events, and thus ignores mouse and keyboard events.

Unless you see any problems with this, I'll commit the change when I commit 
the relevant changes to kdenlive. There is a very good chance that this will 
be sometime this week, I'm not at work :-)

> > Idea 3 : Have a separate 'drag' box on each monitor that can be used to
> > drag clips to the monitor.
> > * advantages - Definitely works, quick to implement.
> > * disadvantages - Not a good solution for a UI point of view - the user
> > will want to be able to click on the clip image to drag it, not on some
> > little drag icon the side of it.
> >
> > What do you think?
>
> I think I would like a mix of 1 and 3.

> 1) I don't think piave is the right place to handle mouse/keyboard events.

Agreed

> Eventually we need to draw points an boxes on the monitor which need to be
> dragged around to position PicInPics and Text and paths for moving effects,
> etc. all this needs a lot of mouse action and surely needs to be handled by
> kdenlive.

I agree - I think there may be some trouble when it comes to handling the 
visuals for editing pic-in-pics and text, etc. but that is a seperate issue. 
(My thoughts on this - I don't believe it should be up to piave to display 
control points, etc. on top of it's image, this should be controlled by 
piave. Now, exactly how we put kdenlive control points over the top of 
piave's image is a difficult question to answer. I have some ideas, but 
nothing concrete right now - I'll start another thread in a moment :-)

> 2) Do I understand correctly that you want to drag the clip by actually
> clickin into the video window? Why? Why not make it analog to the timeline
> and make the clip in the ruler selectable and then drag the highlighted
> part of the ruler, which represents the clip (after in/out cuts) into the
> timeline? Isn't that a viable solution from a UI point of view?

Oh, I see what you mean. Yes, that would be a viable solution.

Once the monitors can support drag'n'drop in some form, it will be straight 
forward to change essentially where in the monitor we drag from, although a 
little extra work would be needed to add support in the ruler to have a 
draggable clip rectangle.

Cheers,
Jason

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