GNOME Bugzilla – Bug 655513
brasero invoked via "Open With" from KDE/Dolphin right-click does not exit
Last modified: 2014-01-03 13:13:53 UTC
If brasero is invoked from the KDE desktop by right-clicking on an ISO image in the Dolphin File Manager and selecting "Open with" brasero, the burn window showing the source and target opens and the burn completes normally. However, after you close the burn window, there is still a brasero process running. Because of this, any attempt to repeat this process on another ISO image fails without any error, as brasero will not start if it is already running. This can be verified by attempting to start brasero from a command-line. The problem appears to be that the desktop entry for brasero specifies Exec=brasero %U, and the primary brasero window is hidden somehow so that only the burn window appears. However, the process for this window never ends. If the desktop entry is changed to invoke brasero with the -i switch, the problem does not occur. The original bug report is at https://bugs.mageia.org/show_bug.cgi?id=2158
I'm experiencing this same bug, exactly as described by the reporter, but I'm on fedora 19 with brasero 3.8.0, this means this is a general bug and not kde related.
This turned out to be a logic issue in the way Brasero starts up. What is happening is that when the burn dialogue is dismissed Brasero tries to continue starting up and show the main window, however as the main window had never been created (because it was bypassed in favour of showing the burn image dialogue) this operation failed and Brasero was left running without any UI shown. I've developed this patch to resolve the issue: https://git.gnome.org/browse/brasero/commit/?id=f122ee0620380b7c21edce722cfe347f10c8c827 As it's unlikely a user wants to be dropped into the main Brasero window when they've finished a burn operation launched this way it simply ensures that we don't try and present the main window when it hasn't been created, leading to Brasero to exit as expected.
*** Bug 679905 has been marked as a duplicate of this bug. ***