published Dec 04, 2006, last modified Jun 26, 2013

I had a small epiphany a few minutes ago. I'd like every KDE application to support a --renderToImage argument, through the KApplication class.

Am I crazy?

The idea behind this feature request is quite simple: KDE applications should be 'service-enabled'.

KDE already includes an extremely rich plethora of IPC and reusability mechanisms. It would be completely fair to say that KDE is the single most remotable and serviceable desktop environment ever invented. Except their applications' outputs cannot be used (without jumping through a lot of hoops).

An example drawn from personal experience: I use Subversion heavily. I have a couple of KDissert diagrams pertaining to a project of mine. I regularly use Kompare and Web repository tools such as Trac to visually audit changes to a project.

Oh, how much would I love for these tools to support some sort of visual diff for non-text images! Only it is impossible to implement without a way to remote GUI applications such as KDissert so that they produce graphical output.

Sure, a Frankestein concoction of a memory buffer-based X server could work. But that's subpar because we want the entire printable object to be exported, without user interface elements. Plus, the latest Qt library does not require an X connection, so there's one fewer reason KDE applications could not be used as standalone command-line tools.

Of course, this could all be implemented as a per-application feature. For example, there's a command-line application that uses KHTML internally to screenshot a Web page. That's all nice and great, but I'm aiming for something greater here: to establish this 'command-line switch' as a standard protocol and to minimize developer takeup time. Hence the idea of implementing this as a --renderToImage switch.

That'll make my Subversion diffs a whole lot more entertaining.