[Kdenlive-devel] KDEnlive Bugs I encountered

[Dan Dennedy]

On Thu, Jan 19, 2012 at 2:01 PM, el jefe delito <eljefedelito at gmail.com> wrote:
> I am talking out of my backside here, as a non-programmer, but...
>> How can you handle a crash in a nice way? An application shouldn't
>> crash, but when it crashes it's too late.
>
> How does an app crash and not bring down the whole OS?  How does Adobe Flash crash often but not bring down Chromium?  How does the Desktop Capture crash and not bring down KDEnlive?  Is there a way to do something similar in other parts of KDEnlive, and allow these parts to be restarted?
>

These occur through process isolation. Web browsers like Chromium run
each tab and plugins in separate processes from the browser shell.
Kdenlive already spawns separate processes for screen capture,
transcoding, and rendering thereby protecting the editing project.

Kdenlive could potentially run the bulk of its editor in a separate
process and leave only the window and perhaps a dialog upon crash -
something like Firefox does as Brian mentioned. That would only add
minor user experience sugar over simply using the desktop environment
to restart kdenlive.

Now, the more extreme approach that would require serious engineering
is to run the majority of MLT in a separate process. To do this
strictly from MLT to Kdenlive would get messy due to things like GUI
toolkit and the way XVideo is being used today for better performance.
We may be able to add around something around MLT that runs the main
object graph in separate process and uses shared memory to transfer
the audio and image to a parent process using the MLT output plugins.
But that will also require the addition of a complete IPC layer over
the MLT API so the Kdenlive logic can still manipulate the object
model of the composition. And in the end, all that buys you is MLT
isolation, and crashing bugs within Kdenlive code still leaves
Kdenlive vulnerable.

-- 
+-DRD-+