Often I read comments about people wondering why krita require this or that library, and therefor will not work without it. Like in the last dot announcement about koffice 1.6, or in a bug report asking for krita to be separated from koffice.
The three hard requirements of krita are kolibs, qt/kdelibs and lcms. It’s nearly impossible (unless making a local copy of those one in the krita tree) to build krita without any of them. And as I will try demonstrate bellow, we make an extensive use of those libraries.
It’s probably the most hated dependency of krita. “Why is that krita is part of KOffice ? No other Office suite include a bitmap manipulation program !” “Surely there can’t be much in common between a spreadsheet program and krita.” Well that’s true. kspread and krita are probably the two applications of KOffice with the less in common.
“So surely you can’t find a common point between a presentation editor, a word processing and krita ?” Well that’s wrong, both kpresenter and krita are very demanding of a powerful text engine, and kword is able to provide that, for a little work on our side. And further more, the three applications are very demanding of whatever vector graphics can be provided by karbon.
And that’s just small example.KoLib bring us (or will bring us) a filter and shell architecture, a powerful text engine, vector graphics… and much more.
Furthermore everything is not about code, while this blog entry is mostly about it, but being a koffice application allow to share administrative effort: like releasing, webmaster, public relations…
I also read some comments wondering if a gtk port of Krita is possible (beside the question of the usefulness of the idea), it’s hardly possible, I can’t think of a single file in Krita that doesn’t use a Qt class.I guess some people tends to think that most library are use superficially at the outside border of an application. This is definitively not the case. Qt/KDElibs is a framework, not that we use everything possible, but as soon as something we need is available in the framework, we make sure to use it. So while in our code, we have a clear separation between the image manipulation library and the UI, that doesn’t mean it’s possible to use the image manipulation library without the framework. Qt/KDElibs is definitively not just about GUI, and I think that trolltech has made it very clear that they want Qt4 to be use in non GUI application by clearly splitting Qt4 in different libraries.
There is more to color management than just displaying the right color on the screen or printing it accurately. It’s a misconception that lcms is only used for those two tasks (beside the fact that printing is not yet correctly implemented). A simple task like brightness/contrast is a color management task. And actually, using the filling tool also use a lcms function (which was the main reason why 1.15 is the minimal requirement for the latest version of krita). In fact, it’s the less needed library of the three, with the current architecture of krita, it’s easy to wipe out lcms, but that would still requirement more than a week of hard work to cripple krita.
But the plugin architecture protect us from most of the requirements
For instance krita is depending on GraphicsMagick (or ImageMagick) for reading various image format, but it’s a weak dependency, if someone doesn’t need the support of those files, then he just don’t build the corresponding plugin. That’s what does Fedora Core, they don’t consider that those file format are worth it, so they don’t ship the plugin.
Krita also support python and ruby scripting, but none of them are needed to run krita.
So when it makes sense, because it doesn’t require a lot of work on our side, or a lot of duplication of an already existing work. Then we make our best effort to have krita independent of that library.