Popular CD and DVD burning application for KDE, K3b is gearing up for its first port to KDE4 with a pending 2.0 release, but part of the Qt toolkit had to be forked to make it possible.
K3b version 1.0 was released for the KDE 3 series in 2007, but since then it has been a non-trivial port to the new KDE4 platform for lead developer Sebastian Trueg.
“Where is it? Well, it is on its way, as it has been for the last few years,” Trueg wrote in a blog post.
Mandriva Linux wanted K3b done for its 2009 Spring release (due April 29, 2009) and assigned two developers on the project part-time reporting to Trueg.
“This was a nice but also wise move,” he said. “Everybody who ever worked on K3b or sent patches knows how protective I am of its code. So by letting two developers work on K3b, Mandriva kind of forced me to work on it too. I am finally enjoying hacking on K3b again.”
If all goes well K3b 2.0 will be released with Mandriva 2009 Spring, but that is not certain because Trueg had to fork Qt's QProcess class to simplify the port.
In KDE 3 KProcess used pipes to communicate which allowed Trueg to implement K3bProcess which was used all over libk3b to pipe data from one process to the other or between processes.
The advantage was high data throughput and unnecessary asynchronous behaviour so “life was good”.
But with KDE4 KProcess became a convenience wrapper around the cross-platform QProcess, which Trueg believes is a “good concept”; however, “the internals of QProcess are hidden and its API is way too high level for K3b’s needs”.
To work around the problem, Trueg tried to change the multi-threaded design of K3b to an asynchronous one, but that didn't work and was “yet another useless coding round”.
“I did not really like the idea since that would mean that data pumping would have to share event cycles with GUI updates and user interaction,” he said.
“So finally I realised that I really needed a fork of QProcess (and with it KProcess since that is what K3bProcess is based upon) and that is what I did.”
By his own admission, Trueg did not change much in QProcess, but the new code does “exactly what I want”.
“Now K3b can pump its data as before and it works swimmingly,” he said. “This whole development took forever, but in the end I think it is clean and fast again. And once Qt Software will include the unbuffered mode in Qt, all communication becomes cross-platform, too (I did only patch the Unix portion).”
The changes made for the KDE4 port may also mean “in theory, at some point” K3b will run on Windows in addition to Linux.
“I already have a patch for Windows support at libk3bdevice level [and] have had that for years now. Only need to apply it. Once my QProcess fork is ported to Windows we are good to go.”
Unfortunately, Trueg has also learned that Qt Software will not implement a blocking API so he will have to maintain the fork.
“The unbuffered mode does only make sense for me if it is blocking, otherwise I am in multi-threading hell again,” he said.
“Too bad, it could have been so easy…”