developerWorks: Coding with KParts

David Faure, proud owner of an excellent t-shirt, has written a very nice article for IBM developerWorks. David gives a beautiful overview of KParts and touches on everything from DCOP to XML-GUI, XParts, and CORBA. "KParts is also used in more high-level interfaces, such as the TextEditor interface. The former is a complete interface that models the API of a text editor so that applications can interchangeably use any text editor available that implements this interface. vi users will love being able to type mail in KMail using a vi text-editor component (such a component is under development). A general ImageViewer interface is under development as well." Great to see KDE development getting the exposure it deserves.


By reihal at Fri, 2002/02/22 - 6:00am

Well, in the Resources section, the link to the chapter 12 is a link to the book, at least its copy on developer.kde.org.


By David Faure at Fri, 2002/02/22 - 6:00am

On Apps.kde there is still version 0.1, which was submitted September 12th 2000. And the homepage-link doesn't work anymore.
KVim would be great. I hope someone is still working on it, but just too shy to talk about it...

By Michael at Fri, 2002/02/22 - 6:00am

Yes they are working on it but afaik it will be quite useless to most people because it will not sport the KTextEdit interface. I hope I am wrong about this but I would not hold my breath. Personally I think a VI style editor makes little to no sence in a GUI, but I also like editors like emacs and Kate. ESC-:-wq vs Ctrl+S - Ctrl+Q really it makes no sense or is there something that Vim can do that Kate cannot?

-ian reinhart geiser

By Ian Reinhart Geiser at Fri, 2002/02/22 - 6:00am

Yes. AFAIK Kate does not have folding and integrated Diff/Patch support. Also remapping a key or keysequence with a complete sequence of keys. E.g. :imap /***/hhxkkA - to create a shortcut on the key F5 for



:imap dre der

to implement something like autocorretion. IMHO there are very much features (at least in VIM 6) which are currently not supported in Kate. (Is there support for block selection in Kate?)


By Emmeran "Emmy" ... at Fri, 2002/02/22 - 6:00am

kate will have code folding fairly soon. i've got an early version of it on my system right now from the code_folding cvs branch. =)

By Aaron J. Seigo at Fri, 2002/02/22 - 6:00am

There is some work going in a branch in KDE CVS on code folding, AFAIK.

I don't think the remapping functionality is there per se, but adding a plugin to paste certain text segments seems easy enough for any qualified programmer to do quickly -- in fact, it looks like the Hellow World plugin example is nearly it. I might even consider trying to implement one, and to smuggle it into 3.1 ;-) And IMHO, using plugins for those sorts of things is the right way of doing it -- with a C++ interface, Kate is more programmable than just about anything there is (OK, one can do lots in EMACS lisp -- but if you're a C++ programmer, wouldn't you rather use your preferred language?)

BTW, why would you need the feature for your example that if there is a nice easy-to-use comment-out feature?

If by block selection you mean selecting rectangular areas of the text then yes, it's supported -- Settings->Vertical Selection

By Sad Eagle at Fri, 2002/02/22 - 6:00am

Wow, I did not follow the kvim development, because it had stopped for a long time.I just found the HP:


Well does vim do things kate doesn't? You must be joking. kate is a small child compared to vim-6.0. vim has configurable syntax highlighting for everything. vim has decent completeion, a million of features which you won't see until you look for them becasue they HELP you in your editing.
Seriously, kate is nice, but vim is so advanced, you wouldn't believe it.

By Moritz Moeller-... at Fri, 2002/02/22 - 6:00am

I see... well i dont see really, i can see what Kate can do... I have no clue what Vim is doing half the time, but that is a personal problem. ESC-:-hkkhhsh... whatever... That is not how things operate in my world.

I know the scripting support in Kate is still in its infancy, but the syntax highlighting is very nice. Via dcop and the ability for Kate to use KScript you can manipulate your document via DCOP. The plugin system also allows for a greater level of expanabilty. I am a firm beliver in usability over wizzbang features, hence why I use KDE instead of something like Gnome or FVWM hacked to heck... I think in the next year we will see Kate pull ahead.

just my 2c...
-ian reinhart geiser

By Ian Reinhart Geiser at Fri, 2002/02/22 - 6:00am

Well I actually don't know much about the power of kate vs. vim. I'm just used to vim and I don't see any reason to change to anything else. So far none of my friends could show me any feature in any other editor, which would cause me to change the editor. I mean: never change a running system as long as you don't need any new features...
However I agree that many people are not used to something like "ESC :wq" and I don't have any problem with them. I think everybody should use his/her favourite editor, that's why I would wish many KParts (hopefully including vim).

By Michael at Sun, 2002/02/24 - 6:00am

Yeah, you are right, vim is quit advanced, but I don't really want to reprogram vim, because that would be really senseless, users which like vim wouldn't switch to a vim clone and new users would say: "why use a clone if you can have the original ?"
Kate is not a vim/emacs clone and hopefully won't get one ;)
Some of the vim/emacs/nedit/ultraedit/scintilla features (like folding, dyn. word wrap, ...) are very nice and we should try to get such "more advanced" stuff working, but I think for a project started around 1-2 years ago around the old KWrite codebase, the Kate KPart/App isn't such bad ;) And I even think our syntax highlighting is really one of the strong points (look at the new xml hl in the kde CVS, really nice, only a few typos inside) and the textbuffer we use isn't that bad (exspecially for bigger files), too.
And from view of the KParts side: Kate is the only real implementation of the KTextEditor interfaces of kdelibs at the moment and one of the only real editor kparts for kde 2/3 which actually work ;)
My opinion at all is:
Vim/Emacs/Nedit and some other are really much ahead in some areas, but I hope we catch up at some important points as code folding, word wrap, scripting, .... but (K)Vim and the others need to catch up too in point of the kparts support.

By Christoph Cullmann at Fri, 2002/02/22 - 6:00am

> Why use kvim when you can have the original?

Simple. I would want vim to replace everything that uses text editing/input
in KDE. I am used to the vim keyboard layout, it is not intuitive, but it
isn't supposed to be - it's supposed to be effective. I have problems with
my hand joints (Sehnenscheidenentz√ľndung in German) and I'm not able to use
Shift or CTRL (ie. the 5th finger) more than absolutely necessary. I have
already remapped my keyboard to use caps-lock as a second Enter, and the
windows keys as second backspace / delete keys, but that only distributes
the "fifth finger load" between hands, it doesn't eliminate it.

Escape-Meta-Alt-Control-Shift (and xemacs) are completely out of reach for
me. Even cutting and pasting with CTRL combinations are awkward, I don't
like taking my fingers off the default positions just to move the cursor
(let alone to find the mouse).

Plus, I always tend to hit ESC when finished writing, which - e.g. in licq -
makes me yell "SHIT!!!" 2 seconds after having written a 1000 word message to

So, if this is in any way possible, I want a kvim plugin to (OPTIONALLY!)
replace Konqueror's s, to replace multiline edit fields, and to replace
the default editor widget that plugs into everything.

I think this is possible, and I will try to help anybody who dares.

Of course, this is only MHO, and YMMV. HAND.

(btw you have no idea how long typing this messages took, with all those
capital letters =;)

By Jens at Sat, 2002/02/23 - 6:00am

Sorry, but I think you should quote me right (or try to read what I write better), I never wrote

"Why use kvim when you can have the original?"

I just pointed out that I don'T want Kate to be a (k)vim clone. I never said I don'T want the development of kvim ;)

By Christoph Cullmann at Sat, 2002/02/23 - 6:00am

Sorry, I actually wasn't quoting (this was more intended to be an answer to
what I thought the 'gist' of your message was.

If I misunderstood, sorry. I tend to read too quickly these days.

By Jens at Sat, 2002/02/23 - 6:00am

No prob ;) I make the same thing too often, too ;)

By Christoph Cullmann at Sat, 2002/02/23 - 6:00am

The most exciting thing about a vim Kpart is not the email writing, but embedding it into KDevelop. Many coders like using vi(m) for programming and once you get used to it, you don't want to change. A Kpart gives you the ability to use the power of KDevelop with an editor that makes you effective.

By cosmo at Fri, 2002/02/22 - 6:00am

KVim would be _nice_.
KEmacs would be *GREAT* :-)))
But that would be a really complicated (but also really damn great) project.

And since I'm probably already off topic here let me ask for a KDE GUI frontend for Octave!! Ocatve is GPL and great for numerical computation and could be an alternative for MatLab for many people if it had a decent GUI.

By J.A. at Sat, 2002/02/23 - 6:00am

I agree a KDE GUI for octave would be really great. Math/computation programs are missing under linux...

By Thomas Capricelli at Sun, 2002/02/24 - 6:00am

Well, I wouldn't say Math/computation programs are *missing*.
Both Mathematica (algebraic computation) and MatLab (numerical computation) have Linux versions. I'd just like to see more and better open source or at least freeware tools.

There is MuPad (algebraic computation), which is kind of free and pretty good. For numerical computation there is Octave but the GUI is missing.


By J.A. at Sun, 2002/02/24 - 6:00am

KVim is alive
KVim as a standalone app is working really nice, and you can find it in kdenonbeta

KVim as a embedable component was/is very hard to get. But we'll release kvim-0.2 RSN. It will probably be announced on the dot, and doubtlessly on www.freehackers.org

see ya.


By Thomas Capricelli at Sun, 2002/02/24 - 6:00am

Something I had thought about way back when was using QT XT widget support to embed the xemacs widget in an application. But at that time the status of the widget seemed to be experimental and I couldn't find much information. This was quite a while ago.

Now the last time a got the latest release of xemacs, of the top of my head, it seemed like more work had done on it. I think it would be really nice to be able wrap a KParts interface around the xemacs widget and use it in KDevelop. Hopefully this would allow you to use all the nice lisp packages, taking advantage of all the great resources available for xemacs. One that I really like is word completion based on the buffers you have open.


By Willy at Fri, 2002/02/22 - 6:00am

'C++ only' isn't strictly true. In KDevelop 3 you can write KParts in Java (see kdevelop/parts/javasupport or the java plugin project template). They need a common C++ stub to start, and the rest of the code is just java. The KDE java bindings have enough event callbacks and slot/signal handling to allow you to do pretty much everything you would in a C++ part.

The advantage of writing KParts in java is that you can compile them to platform independent JVM byte codes, and then download them from the internet (ie partlets?) into a running app..

-- Richard

By Richard Dale at Sat, 2002/02/23 - 6:00am

I am confused by the docs on that subject.

How can the kparts loader know what to run? Or is the final Java code something other than a JAR. I have been trying to find docs on the subject, mainly because I want to be able to load KParts created with PyKDE, or maby even some other future language.

The partlets bring up an VERY cool idea though. I am a little curious on the secureity of the plan but really it looks like what .Net promises... only now ;)

-ian reinhart geiser

By Ian Reinhart Geiser at Sat, 2002/02/23 - 6:00am

"How can the kparts loader know what to run?"

The factory class from the C++ stub, 'MyTestFactory' here, uses KStdDirs/KInstance to find the jar file, and adds it to the class path. It then loads the corresponding java factory class. The MyTestFactory::createPartObject() method constructs an instance the java class 'MyTest' to start the part running.

MyTestFactory::MyTestFactory(QObject *parent, const char *name)
: KDevFactory(parent, name)
classPath = "file:";
classPath += instance()->dirs()->findResourceDir("data", "kdevmytest/kdevmytest.jar");
classPath += "kdevmytest/kdevmytest.jar";

env->CallStaticVoidMethod( urlLoaderClass,
env->NewStringUTF((const char *) classPath) );

cls = env->FindClass("MyTestFactory");

Bernd Gerhmann thought it might be possible to use the same C++ stub for different parts. He wrote:

"Perhaps it would be possible to write a generic C++ part that
can load arbitrary Java parts? (well, it least generic for a
given service type). In the .desktop file you can define
a keyword X-KDevelop-Args whose contents are given to the
createPartObject() method. So in principle one could think about
replacing $APPNAMELC$ in the template by the 'args' string that
createPartObject() gets. This way, you don't have to compile C++
code for each java part."

So it needs more experimentation. Python or java code should just be another resource inside a kpart wrapper directory, and the part would just look normal to the outside world.

-- Richard

By Richard Dale at Sun, 2002/02/24 - 6:00am

I think this is the most effecive solution. This is what korelibs and ActiveX Controls seem to do. They Although from what I can tell for writeing COM objects in Python you have to wrap the individual python module in some code, in my mind defeating the purpose of writeing the module in python anyway :\

The only issue that seems to come up with this is how to deal with multiple instances of the plugins. This I have not researched very much.

I think this will be a big part of KDE 3.1. I think by that point we will be seeing KDE components written in Python Java and hopefully even Ruby as this matures. One other thing we need to keep our eyes on is dcop and dcop services. These too in my mind will help integrate 3rd party modules into KDE. The one GREAT advantage of DCOP based extentions is no BIC issues :)

-ian reinhart geiser

By Ian Reinhart Geiser at Sun, 2002/02/24 - 6:00am

All the example code that I quoted from MyTestFactory::MyTestFactory() could be moved to the MyTestFactory::createPartObject() method, where the part name string would be available from X--Args, as per Bernd's scheme. So it does seem possible to write a generic C++ part wrapper for particular languages like Java or python.

KDE/KParts has a good resource location and packaging mechanisms, which fit very well with script code (eg Ruby or Perl) or java bytecodes in .jar files. No need to have a common runtime, it is more important to have a common Qt/KDE object model, plus KParts packaging.

-- Richard

By Richard Dale at Mon, 2002/02/25 - 6:00am