K3b 2.0 coming to KDE4 mid-2009, Qt forked for port

Changes mean Windows port now possible
K3b: a much loved CD and DVD burning app for KDE and Linux

K3b: a much loved CD and DVD burning app for KDE and Linux

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…”

More about: KDE, KDE, Linux, Mandriva
References show all

Comments

1

Seb Ruiz

Tue 24/03/2009 - 23:03

Saying that Qt was forked for the port is gross exaggeration. There was simply one class which was no longer suitable for the job, so Trueg implemented the old functionality. It happens very often that developers will take some piece of upstream code and maintain a patched version in their source tree for guaranteed functionality.

2

Anonymous

Wed 25/03/2009 - 09:22

I agree with the first post. One class was forked. The writer does not seem to have clue

3

Anonymous

Wed 25/03/2009 - 09:49

"BLOG"

The whole article is just a quote wrapper about Trueg's blog post: http://trueg.wordpress.com/2009/03/23/intermission-why-i-needed-to-fork-qprocess-for-k3b/

Kind of lame techworld

4

espi3d

Wed 25/03/2009 - 19:40

You always can do a blocking component from a non blocking one by using locks and events/conditions. That would be a much cleaner and easier solution to this problem.

5

Ruth

Tue 31/03/2009 - 16:15

hi

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

Ruth

http://systemmemory.info

Post new comment

The content of this field is kept private and will not be shown publicly.
Users posting comments agree to the TechWorld comments policy.
Login or register to link comments to your user profile, or you may also post a comment without being logged in.
Related Coverage
Related Whitepapers
Latest Stories
Community Comments
Tags: DVD, k3b, kde, kde4, mandriva, Qt, Qt Software
Whitepapers
All whitepapers

Twitter Feed