Thomas Capricelli, Philippe Fremy, and Mickael Marchand are pleased to present the first ever stable version of KVim, finally bringing us "the power of VIM with KDE's friendliness". In case that means nothing to you, VIM stands for Vi IMproved and has become the defacto standard version of Vi on most Linux distributions. Vi is the traditional, ever popular, text editor on UNIX systems which can sometimes be a challenge to new users. As the names imply, VIM adds many powerful improvements over Vi, and KVim wraps the whole thing up in a nice KDE interface. Best of all, KVim offers a KPart for out-of-process embedding in KDE. The KPart can currently embed either of GVim or KVim in Konqueror, but further work is required before proper support for KDevelop, KMail and Kate is available. It also looks like KVim will be integrated into the main VIM source distribution in the future. Great news!

Side note: Interestingly, one of the first articles ever on KDE Dot News concerned the first developer release of KVim. It generated quite a bit excitement at the time, although it seems we jumped the gun on the KDE/XEmacs rumours. :-)

Okay, maybe I am just missing something, but how do you use KVim in Konqueror? I have downloaded/compiled/installed the complete KVim package and can use KVim as stand alone without any problems(look great!). But I can find no way to use the KPart in Konqueror. Any instructions would be very much appreciated.

I'm an emacs user myself so I haven't tried this, but I'd imagine you just need to change the preference order in your file associations. Open up the settings dialog and choose the file associations section, then look for text/plain and see if you've gained a KVim option under the embedding tab.

the instructs say after running testVim go to the /kvim/vimpart/kde-version directory and run ./configure, make, make install. the problem is that there is no configure script in that directory. i tried make -f Makefile.cvs, but it errored out. so i'm looking for a little help with this too.

Okay, I figured out that the error I was getting when doing the 'make -f Makefile.cvs' was from having an older version of autoconf. After upgrading it worked great, thanks.

One note, in the output from doing the 'make -f Makefile.cvs' with autoconf 2.13 you get the following message:

*** YOU'RE USING AUTOCONF 2.13. We suggest updating.
*** autoconf 2.5x works best for now, we will drop
*** support for autoconf 2.13 soon.

Quickly followed by some errors that halts the make. After tricking the make into getting by these errors, I was then presented with this message:

FATAL ERROR: Autoconf version 2.50 or higher is required for this script

I think it would be a little more useful if the first message just said this to begin with and then halted instead of trying to continue and saying that support will be dropped "soon" as it appears to have already been dropped.

You'll be happy to know that we're working on kvim-6.1, that should be released not so far from now. Featuring a sync with vim-6.1 and lot of bug fixing from the kvim-6.0 release. Also, we've started to talk with the kdevelop people to see how to make the vim part a KTextEditor, stay tuned.
You can come and see us on #freehackers or #kde (on the openproject network)

I guess he means that there's only one filelist in most filechoosers, where he would like to see a list containing the directories and another one (next to it) with the actual files. Though the current behaviour doesn't hinder me, that seems like a good idea. Though directories are in fact just another file, they differ quite a lot from the user's point of view. I believe the old KDE1 did it this way: at least my KLyX that I still use has a separate dirlisting left of the files.

>Hey, you know what, I love KDE because it is so fantastically flexible and >configurable -- in this case :

Well, it is configurable only on the surface, superficially...

>Right click in the fileselector window, and you are given the option (amongst >others) to have dirs and files separate.
>In fact, try right-clicking on all widgets : there is a wealth of config >possibilities in all of them !

Yes, it is a begniing. Especially the embedded console is a good idea.

But this still is an excuse of a filemanager, not more. It seems to me you never used a 'real' filemanager, you would see how much this is worlds apart.

The only really good filemanager I came acrosson Linux was Worker and MidnightCommander.

No eyecandy, though. Note, that each of the four listers you see here is a normal window, they have been arranged (probably by a keypress) to occupy the screen in this state. Of course all is supported (cut,copy&paste, drag&drop) as well as doing all kind of funny things (all basic tasks like copy,move,rename,link,archive,dearchive) and whatever by the buttons you see. Also note, that the "listers" can be used in icon-mode as well.

I still do not see any way to archive a bunch of files with Konqueror without opening the embedded console or maybe drag&drop into an opened archive.

Oh, and since we are at screenshots and my favourite computer system, have a look at here:

Directories /are/ files. They're just files with links to other files. In fact, rather than separate out directories, they should be handled like files even more than they are, and files should look a lot more like directories.

Directories should be able to have mime types and associated applications. I'd like to be able to create NeXTSTEP-like .app folders that are executed like applications. Files should have directory attributes; I'd like to create associations between files, so that files can be browsed like directories.

The separation of directories and filesystems is a limited metaphor. BoOS, with its DB-based FS was a step in the right direction, but encountered some engineering problems. A very good example of what filesystems /should/ look like is at http://www.reiserfs.org/whitepaper.html. In the short term, artificially increasing the similarity between file nodes and directory nodes is a good thing to do.

You mean that it should be possible to specify drop actions like running
a certain program when a file of a certain mime-type is dropped on a folder?

This would be a very good idea, but this is not somthing that should be handled
by a GUI like KDE. This should be handled at filesystem level. That way we get
no inconsitent behavior if files are moved or copied with other tools or programs
than the filemanager.

>I'm kinda curious about what you mean by this. How would you like it to be >done?

Well, just check it out. Open up Konqueror in Filemanager mode.
The most blatant hint you will get (at least if you use the german locale) is the very first menu, it is named: "document" (or maybe "file" in the english locale.

Now you should get it.

If still not, have a look at the "Edit" menu. You find the Cut,Copy&Paste items there. Typical for a document-application. (I think, however, that a "real" filemanager should have these as well, since it is a good idea, but it should not be the only way to copy/move files besides drag&drop.)

This kind of interface to access directories was invented by Microsoft. It is a good idea onthe one hand, since it adds consistancy to the user interface.

On the other side it is a horrbile idea, since a directory is completly different from a two document like a Word file, spreadsheet or DTP doc.

Also the treeview is not the best way to represent deeply nested directories. As soon as it is deeper than three or four levels you find yourself resizing the tree-panel already. And this just to name one of the many misconcepts in this.

Also, with these programs (IExplorer, Nautilus and Konq) it is difficult to do power-filemanagement, since the windows are designed in a way, that it is impossible to have several open (on a normal reso like 1024x768 or 1280x1024) without cluttering each other, at least in parts (I am talking of more than 3 or four windows here).

Even than, there is simply no way to add user-defined buttons/menus/shortcuts or popups, one of the most important feature of any decent filemanager.

A "real" filemanager has at least two identically set panes next to each other. Even better four (two on each side but breowsable) even better - as many as you like, layouted in a fashion that allows quick and fast access to many such panes (or better name them "listers).

There are some attempts to give Linux a good filemanager.
Krusader, which is too simple.
Gentoo (the filemanager, not the distro ;-)) which is better.
Even better is Worker.

Note, that Worker and Gentoo claim to try to imitate a program they reference as "Dopus". Which is short for "DirectoryOpus" the mother of all Filemanagers (it was introduced on AmigaOS and was fully scriptable and configurable. On AmigaOS, configuration of an app means more than moving floating panesl around and adding another theme, it measn usually tailoring all buttons and menus with commands/scripts the user wants.).

Dopus got even better in V5 (and now on Windows it is reviewed as one killer application onmany sites, it is v6). On Amiga it replaced the whole desktop and offered as many views/listers as one wanted. I would like to see a similare approach (without loosing KDE as desktop) with kparts and whatever.

Actually, the first menu is named Location in the English version (at least in 2.2.2). Also, it's important to note that Konqueror is _not_ a file manager. It's a multipurpose app. CC&P is certainly appropriate for a web browser, which Konqueror is, and for many other things that Konqueror does (like PDF viewing, etc, etc). However, I do agree that Konqi's interface is a little contrived at parts. I remember the Konqueror usability study, that had some great ideas that were consequently ignored. Strange, that...

Also, add TkDesk to the list of file managers that are good. Practically everything is scriptable. It doesn't have that multi-pane mode on by default, but you can set that easily enough.

Yeah, it should at least be possible to remove the file manager part and replace it, the same way that you can replace KHTML with Gecko for HTML rendering (though hopefully a little bit more stable :-).

I use gvim with the default colour scheme, and that's fine for me, but kvim with the default scheme seems to not have the same amount of contrast...the colours are all a little too light, the dark blue colour scheme was the closest to being useable for me, but I prefer a white background.

I verified that default.vim was identical in both gvim and kvim, and I copied the c.vim from the gvim installation to the kvim one, so they were the same too (though they only differed by a couple of lines relating to comments originaly anyway)

You can see that the colour test pages are nearly identical, whereas the c syntax examples are quite different.

Another thing I noticed is that kvim seems to handle fonts weirdly...when you select a font in the font selection dialogue, the one you actually get is different, and I'm unable to get the same font I use in gvim at all....though font issues may be more of a problem with the KDE libraries in general....

this is a really 'strange' bug, it will need some investigation
what I can't understand is why the color test is ok whereas the real C syntax highlighting looks different, maybe i forgot something in syntax highlighting in KVim.

Concerning the fonts,
I tried to stay X (and gvim) compatible and keep compatibility with XFLD font names : courier-bitstream-*-*-*-14-r-m-*-*-*
I know think it was an error as QT badly handles these (look qfont.html for more precision about it)
so, soon in CVS (probably monday), you'll have only QT fonts supported (and better supported), then any setting saved in your ~/.gvimrc will have to be rewritten like : "courier [bitstream]:10" , XFLD names won't be supported anymore.
That means if you want to save your font setting for kvim in your ~/.gvimrc, you should use something like : if has("gui_kde") set guifont=courier [bitstream]:10
so that it does not give an error when you start gvim (gtk vim) ;)

I discussed with someone on IRC which explained me that the CVS server was quite full at the time we wanted to add the Vim runtime package in CVS (note that full KVim CVS is more than 16 Mb). cvs.kde.org may have a lot of space, probably some mirrors don't have so much.

checkouting kdenonbeta already take hours ;), adding the 16 Mb of KVim would not have helped it. Morover, KVim cannot be anymore considered as a alpha or beta program, that seemed logical to us to have our own repositery.

But don't worry Tuxfamily is a good hosting place :)
CVS is fast and has a lot of space, this is all KVim needs :)

you probably missed the links on our download page ;)
check our download page carefully, section "What do you need ?", there are links but these are not displayed correctly (no underline): the filenames are the links, click on them.
We will correct this ;)

Well... It's good that this works at all, but I wouldn't go so far as to call it "even better". Having the choice of using a real editor instead the basic text widget is good. "Even better" would be what he suggests: not being confronted with a basic, feature-less text widget, but having a real editor from the get-go, anywhere and everywhere.

Yes it is great news :))
After using vim for a long time, I end up moving to Xemacs though.
I still use vim sometimes, mostly when I'm working in console, but vim
is just not enough for my needs.
So, yes I love the idea, many people will use it a lot, I'll probably use
it sometimes, but I want a KXemacs too!!! :-)

First of all, great work! I had been waiting for this to happen for a long time and always knew that it would be just a matter of time. We have also startded up porting Emacs to QT/Kde but it is an enormous task.

About the icons in your screendumps, how do you get Kvim to pick up the KDE icons instead of the one's from GVim? Has anyone gotten Kvim with KDE icons instead of GVim? This totally throws of the uniformity of this wonderful application.

It would really makes sense to have a K[x,]emacs. I think it's probably even more difficult than porting vim. I won't do it, though, I really don't know emacs..
With respect to the icon, we know lot of people want the kde icon. We were actually using them, but as some vim icon are missing from kde
standard icon, we had to switch back to vim/gvim icons. We'll try to get the missing ones.

No - this isn't specific to kvim - it's been happening to me for a bit on
any vim session. There must be some binary in one of my config fils, but I'm not enough of a vim expert to know yet. Was just wondering if this struck anyone.