Version: (using KDE KDE 3.3.1) Installed from: SuSE RPMs OS: Linux If k3b is invoked with the --nofork option, the temporary files are deleted before k3b loaded the files. The --nofork lets kipi wait until k3b is finished before it deletes the files. As workaround you can create a wrapper script with following contents: #!/bin/sh k3b $@ --nofork use this script as the path to k3b.
I implemented --tempfile support in KRun for this kind of problems - but it requires support in the application, I can give more details to the developers if needed. But where does the temporary file come from in this report? (kmail?)
> But where does the temporary file come from in this report? (kmail?) from digikam (does kmail use the kipi-plugins?)
> from digikam OK - then digikam probably uses tempfile=true in KRun( foo, bool tempfile ). In that case digikam is fine, nothing to change there - only k3b needs to be changed (--tempfile support). k3b devels: see kuniqueapplication.h (class docu, CVS HEAD), for details.
On Monday 22 November 2004 18:31, David Faure wrote: [...] > OK - then digikam probably uses tempfile=true in KRun( foo, bool tempfile ). I had a quick look at keg-libs-1 kipi-plugins/cdarchiving/cdarchiving.cpp. No KRun but KProcess: m_Proc = new KProcess(); *m_Proc << m_K3bBinPathName;; *m_Proc << m_tmpFolder + "/KIPICDArchiving.xml"; QString K3bCommandLine = m_K3bBinPathName + " " + m_tmpFolder + "/KIPICDArchiving.xml"; kdDebug(51000) << "K3b is started : " << K3bCommandLine.ascii() << endl; connect(m_Proc, SIGNAL(processExited(KProcess *)), this, SLOT(slotK3bDone(KProcess*))); if ( !m_Proc->start(KProcess::NotifyOnExit, KProcess::All ) ) Because kipi-plugins are used by apps that try to be kompatible to 3.1 and later it would be nice to find a a solution that does not only work with kde > 3.3 and/or k3b from cvs ;). Achim > _______________________________________________ > Kde-imaging mailing list > Kde-imaging@kde.org > https://mail.kde.org/mailman/listinfo/kde-imaging > > >
On Tuesday 23 November 2004 11:37, Achim Bohnet wrote: > if ( !m_Proc->start(KProcess::NotifyOnExit, KProcess::All ) ) And then the tempfile is deleted when the process "exits"? Can't work like that. You need to the --tempfile approach (OK you don't need KRun if you know you're talking to k3b always, then you can just pass --tempfile to it - if it supports it. You could check for X-KDE-HasTempFileOption=true in k3b's desktop file to check it will accept the option, i.e. it's not too old). > Because kipi-plugins are used by apps that try to be kompatible to > 3.1 and later it would be nice to find a a solution that does not > only work with kde > 3.3 and/or k3b from cvs ;). Sorry, can't do magic. The past is the past.
I have added '--nofork' to the k3b command line. This woking fine in MDK 10.1 (this working too without !) Someone can test CVS source code under Suse ? Gilles Caulier
--nofork is a hack though. It means that if k3b is already running, you'll end up with two instances of it. But if k3b is a KUniqueApplication, it's probably to prevent this from happening! --nofork is mainly used for debugging, it's not a good solution to this problem. Hmm, now I'm confused by the subject of the bug. It was always about --nofork !?
well, this confirm that k3b problem is relevant of Suse package. This problem must be fixed by Suse team. Also, i have receive a mail from Sebastian Trueg, the k3b author who explain that: -------------------------------------------------------------------------------------------------------------- On Sunday 26 September 2004 19:35, Sebastian Trueg wrote: | Please please please please don't use this stupid suse version which is | patched to be a kuniqueapplication. Use a decent k3b installation and there | will be no problems of this kind. | And I think you should use an original k3b for plugin, not the suse | patched. -------------------------------------------------------------------------------------------------------------- Well, the good way for solving this problem is to contact Suse K3b packager. Someone can do that ? Too, i will remove --nofork option from command line... Gilles Caulier
I contacted the packager at SuSE. If they wan't k3b an KUniqueApplication, maybe they canpatch the nofork in the plugins, too. This would shift this problem away from the plugin developers.
ok, since it is now clear we are doing the right thing here, we can close this report.
*** Bug 107730 has been marked as a duplicate of this bug. ***
*** Bug 115847 has been marked as a duplicate of this bug. ***
*** Bug 121514 has been marked as a duplicate of this bug. ***
*** Bug 125002 has been marked as a duplicate of this bug. ***