Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

The Union of Vim with KDE 287

Posted by CmdrTaco from the god-bless-integration dept.
Philippe Fremy writes "Thomas Capricelli, Mickael Marchand and me are pleased to present the first ever stable version of KVim, finally bringing "the power of VIM with KDE's friendliness". This release contains a port of the standalone editor Vim 6.0 to Qt/KDE (2 and 3) and a KDE KPart Component. The component can currently embed either of GVim or KVim in Konqueror (screenshots), with out-of-process embedding. Further work is required before proper support for KDevelop, KMail and Kate is available, but things are moving forward." As everyone knows, Vim is the best (only?) text editor, and KDE is the best (only?) desktop system. Heh.
This discussion has been archived. No new comments can be posted.

The Union of Vim with KDE More

The Union of Vim with KDE

Comments Filter:

  • Woohoo! (Score:5, Interesting)

    by larien ( 5608 ) on Monday April 15, 2002 @06:15AM (#3342147) Homepage Journal
    Never again will I end up getting errors when I hit escape while editting an email message...:)

    On a serious note, it shows that we can do things under linux that happen in Windows; the OLE model in Windows has allowed things like this for years, and it's about time we had a similar model in the *nix world.

    • Re:Woohoo! (Score:2, Insightful)

      by j09824 ( 572485 )
      On a serious note, it shows that we can do things under linux that happen in Windows; the OLE model in Windows has allowed things like this for years, and it's about time we had a similar model in the *nix world.

      I find it absolutely fascinating that people think that the UNIX world lacks features found in Windows because, well, because of what? Do you seriously believe that people didn't have the resources to create this for UNIX?

      The fact is that OLE (and its successors) are unreliable kludges. They grew out of some hacks trying to make Office components talk to one another, for which they were sort-of OK. But when applied to arbitrary applications, the GUI merging and process model they give you result in lousy user interfaces and unreliable applications. UNIX didn't get them because UNIX users didn't see a pressing need for them; other mechanisms work better.

      Even if you think that what OLE was trying to do is actually useful, OLE and its successors are about the worst way of implementing it: unportable, low-level hacks that are difficult to version and don't protect programs from one another. OLE is really mainly an attempt to give C++ programs at least a little bit of what systems like Smalltalk and Java give you for free. And, surprise, Microsoft finally caught on and replaced the whole OLE/COM/ActiveX mess with C#/CLR (of course, there is some backwards compatibility and they use the OLE/COM terminology to explain the new functionality in C#/CLR).

      • Even if you think that what OLE was trying to do is actually useful, OLE and its successors are about the worst way of implementing it: unportable, low-level hacks that are difficult to version and don't protect programs from one another.

        Sounds a bit like the WWW when compared to Ted Nelson's Xanadu. And look which one ended up winning. :/

        It's often the quick hacks that sneak in (or are forced upon people :); there was a recent Slashdot story [slashdot.org] about yEnc, which people perceived to be a similar (bad) solution to 8-bit binary encoding for Usenet.
      • It is obviouse from this post that you know NOTHING about OLE, COM, ActiveX, etc. PLEASE get a clue to backup your opinions, becouse this is pure and utter drivel.

        Lousy user interfaces are the fault of the engineer, not of the component technology used to allow embedding..

        And as far as COM being used to give C++ capability, your ignorance shines thru. COM uses 'C' functions. COM is not even away of what the heck a C++ object is. Thats why MFC, ATL, etc, have to wrap it for the less technical folks..

        Get your facts strait..

  • Nice, serious, but no thanks (Score:4, Insightful)

    by MadFarmAnimalz ( 460972 ) on Monday April 15, 2002 @06:18AM (#3342155) Homepage
    Defies the whole persona of vim. vim loses what makes it useful when you stick it in a window and add menus and buttons.

    vim is all about those wierd keystrokes you learn that funnily enough grow on you and multiply your productivity.

    While I'm sure you can still do this with kvim, I don't see what would get a real vim user to use kvim rather than just vim in konsole.

    Nice idea, like I said, but I don't expect too much takeup.

    • You are right that one of the powerfull features of vim is that everything can be done from the console, which multiplies your productivity. Having added window menus and buttons however decreases the initial learning curve. So starting vim users will find it quite easy to do simple things in Kvim, but they will use the console mode more and more once they become experienced users until they become "real vim users".
      • I am not so sure about that. Yes, power users will always find the console mode commands, but most users that start using KVim probably will continue using the menu commands until... well, forever. I know several people that has been using windows, word and other ms products for years, who still go into the menues for cut, copy and paste.
        • Menus are a good way to learn what features a package has when you are learning to use it. It is generally a lot quicker to browse the menu and see what happens than to read through pages and pages of documentation - especially when you haven't yet decided if the tool is the right one for you.

          The menubar on emacs (for instance) is a great way of introducing emacs to complete novices. The smart ones usually find (or redefine) the hotkeys quickly enough.

          • Indeed. When I started using Emacs about 7 years ago, I found the keystrokes bizzare. C-x C-c to quit? Eh? Whats wrong with C-q? ;)

            Now, its just second nature, so much so that I'm always typing it in other editors and getting annoyed when it doesn't work. I found a lot of interesting features poking through the menus. Another nice thing is if you do M-x something, and its bound to a key, Emacs will tell you. If you do it often enough you'll get to remember that keystroke and start using it more and more. My favourite is completion (M-/). I expect that accounts for up to half my keystrokes ;)
        • Those types of people abhore using anything without menus in the first place, so it's still a good choice to add menus to Vim. The thing is, gVim already does that.

          I started using Vim some time ago, and it's the very first thing I install on any machine if I'll be doing much work on it and if it's not already there. .gvimrc and .vimrc are part of my port-a-persona that I carry from machine to machine. If it weren't for the menus on the windows port of gvim I probably wouldn't have been able to learn the commands quickly enough not to loose interest.

          $0.02
      • Menus will not be neccesary for helping people learn Vim once Vigor [userfriendly.org] is fully integrated. Then we can all beg for redemption, and swear we'll never again mess with the text console goodness that is Vi.
      • Actually, the real benefit is using KVim embedded in other KDE applications. If you REALLY like VI's input method, and want to use it in your mailer, IDE, etc., that's where KVim comes in.

        Now if only there was a KEmacs :)
    • vim is all about those wierd keystrokes you learn that funnily enough grow on you and multiply your productivity.

      Of course, but the real beauty of KVim is the KPart. You can use the kvim kpart to edit any textfile in konqueror without opening another terminal and/or window. This is great for hybrid users who love the CLI/Shell but use konqueror or any other file manager every now and then. I usually use graphical file managers primarily for browsing (the local filesystem, not the web) and not for doing real work (like moving files around and editing text files). The KVim kpart might change this a bit.

    • I have always been a serious vim fan, and have used unix and linux for many years.. however, the menus/mouse/buttons/etc in "gvim" (and I assume "kvim" will be similar) makes many functions significantly easier. Cut-and-paste is quick with a mouse, changing the size of windows is fast, and the scrollbar is very useful.
      If I want to quickly write a small file, plain vim is best - but for lengthy editing sessions, gvim/kvim is the best!
      • If you are using menus/mouse/buttons to do normal editing operations(cut&paste,scrolling etc), you dont need Vim.
        OTOH,if you are indeed keen on using Vim, there are plenty of tricks in it that can make you keep the mouse permanently away.

    • vim is all about those wierd keystrokes you learn that funnily enough grow on you and multiply your productivity.

      Well yeah, that's the point. With the kvim kpart (when it's more developed and working with more than just konqueror), people will be able to use their weird little keystrokes in just about any KDE program that uses an editor.

      In particular, I bet there are many programmers out there who don't want to edit in anything other than vim but would like to use kdevelop.

    • yeah you're right. An editor like VIM inside of an application with menus like mutt isn't usefull at all and lowers productivity.

    • Re:Nice, serious, but no thanks (Score:5, Informative)

      by reynaert ( 264437 ) on Monday April 15, 2002 @08:36AM (#3342463)
      Defies the whole persona of vim. vim loses what makes it useful when you stick it in a window and add menus and buttons.

      You'd better reread Vim's design goals. From the documentation [vim.org]:

      Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger.
      This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"
      Vim is designed to be embedded in other applications. An example of this is the integration with Sun Visual Workshop [vim.org], support for which is included in the official version.

    • Three Words (to start with) (Score:5, Insightful)

      by fm6 ( 162816 ) on Monday April 15, 2002 @08:42AM (#3342479) Homepage Journal
      Cut-and-paste.

      When I fell back into the Unix/Linux world some four years ago, my biggest crisis was finding a text editor. The obvious choice for me was Vi in a term window (I've been using Vi since Jimmy was president). Alas using it in a windowing environment presented special problems. The big one is that I kept forgetting which mode I was in. Maybe you can have a half-dozen windows open and keep a state diagram of every one in your head. I can't. I needed an editor that was stateless, or at least less stateful than vi(m)-in-a-window.

      Lucky for me, this was right when the Vim people perfected GVim, a version that integrated itself with various windowed environment. A paste is a paste, never mind what mode you're in. That by itself was enough for me to send a check to Bram's orphans. (I assume everybody else has?) The rest -- macros, synax colors, incremental search, being able to use the same editor on different platforms -- was just gravy.

      So we've actual had this personna-defying version of Vim for quite some time. The Linux port uses GNOME widgets, but runs under KDE, no problem.

      Also, you shouldn't assume that Vim is strictly for keep-my-hands-on-the-keyboard geeks. I know people who are put off by the weird modal keystrokes that Vim inherited from Vi. But they use Vim anyway, because it's the best comprimise available between power and functionality. Most editors are either to limited (KEdit) or infected with Feature Elephantitis (EMACS). Vim strikes a nice balance.

      • Vim is my second-choice general purpose editor. My first choice is nedit, because it's easy to customize for languages that weren't forseen at the time the editor was built.

        I'm sure that Vim can be made to do this, but I've never bothered. Vim is my choice of editor without question in a non-graphics environment, but when it is moved to a graphics environment ... it suffers.

        Emacs to me appears to be the ideal single editor for a non-graphics environment (i.e., no graphics environment is available). It lets you get as fancy as you need to. Vim is a much simpler editor that is quick to learn, but specialized ... it doesn't try to do everything. And it's the editor that you include on an emergency floppy (unless you only have room for pico [or is it nano?]).

        But when one expands into a full system with windowing available ... sometimes a really simple editor is still necessary, but usually I prefer nedit. This is because most of the time the editing that I want to do is some kind of program, and I can teach nedit to handle anything that gre(p) can parse. And I can set tab widths to a 3 without having the program turn them into spaces. I find this quite important, especially for Python programs. (If nests get too deep, I compensate by re-setting the tab widths from 3 to 2.)
    • While I agree with you in part, the part of about using all the funky keystrokes that boost your productivity, I disagree that at GUI version of VIM is less useful.

      For one, the support for native GNOME (in the case of GVIM) and KDE (in the case of KVIM) clipboards, without having to go into the xterm window and keep on marking a "screenful" at a time and then scroll, mark another screenful, scroll, etc....with GVIM and KVIM, you can copy these to the clipboard easily like any other GUI editor.

      If KVIM is anything like GVIM, it will have native support for KDE printing functionality, something non-existant in a console vim.

      The fact that, as someone mentioned, it is a KPART means that other applications can use it. So, for instance, Konqueror could KVIM for the little text editor window that I'm typing in right now and I'd get full Vi-style editing functionality, something that would ROCK if you ask me personally. :)

      Also, adding the menus and buttons give you useful stuff like File Open dialogs. Typing in a long pathname on ':e ' command line is a REAL royal PITA. I'd rather just point and click, thank you.

    • Defies the whole persona of vim. vim loses what makes it useful when
      you stick it in a window and add menus and buttons.

      I'm not so sure. I think it would be great if you could add the contents
      of feedback forms using vi in your favorite web browser (it's already
      possible if you use w3m, for example, or W3 using viper, but some people
      prefer graphical browsers at a decent speed).
    • One word. Fonts! Font support is getting alot better in X and Kde. I can also read code easier from a white background rather then a black. I believe an editor like you said should just edit text. However in today's world you need a documentation viewer, debugger, code designer if your on a project at work, and other utilities to develop code. Visual studio has had these things for years and kdevelop has all of these except a good built in editor.



      The unix way has always been to use one program for one task and connect another program for another. I believe kdevelop which manages your projects and links konqueror for the doc browser, kdebugger for the debugger, and kvim which will replace kwrite for the editor is the best way to go. Ole has had this for years. I also assume that the menu bars will be removed when launched within Kdevelop like kwrite is so there is no worry about lost monitor space. I use vim within Visual C++ on my windows2k workstation at home. Its great to use the commands and still have the full functionality of a whole ide. This is probably why kvim was written and not for just cute little menu bars and icons. If you don't like it you can always use the old vim from a terminal.

    • I'd like to add that GVim did it first, and people didn't really complain too much about it. I guess it's okay if the front end is GTK+. ;-D

  • april 1st (Score:5, Funny)

    by phrostie ( 121428 ) on Monday April 15, 2002 @06:26AM (#3342165)
    this would have been a great april fools joke. Kvim could include an add on module called kflame that automaticaly generates flaming posts. this would force Gvim to release Gflame. these would be followed by Kextinguish and Gwiz. oh please let it end!

  • Justice? (Score:4, Funny)

    by carm$y$ ( 532675 ) on Monday April 15, 2002 @06:26AM (#3342167) Homepage
    Maybe Bill Gates, with his vi background [slashdot.org], will consider using KDE in windows 2004... :)

  • Components are coming (Score:3, Insightful)

    by Shillo ( 64681 ) on Monday April 15, 2002 @06:27AM (#3342174)
    Well, it's been a high time to get real components on UNIX. Considering that UNIX (and Linux) are all about small tools doing their jobs and integrating with each other, components are logical extension of pipes... Now I just wish I had the time to start a project - I'd probably write component browser/method invoker module for zsh. :)

    Anyway... kudos to VIM folks for getting this right.

    --

  • Whatever next - KEmacs & GEmacs? (Score:5, Interesting)

    by ukryule ( 186826 ) <slashdot@yule . o rg> on Monday April 15, 2002 @06:41AM (#3342197) Homepage
    Ah! The acid test for KDE - can it make vi usable for non unix-gurus?

    Given that there is now a version of Vim for both Gnome & KDE, does it make sense for (X)Emacs to make the jump too? I know the origins of Xemacs are as much political as technical - but does it not make sense to try to branch off 2 versions of emacs into the 2 guis?

    I started out making a joke post, but the more I think of it, the cooler i think Kemacs would be ...

  • Google Cache (Score:5, Informative)

    by bobdown2001 ( 528975 ) on Monday April 15, 2002 @06:48AM (#3342209) Homepage
    Well it looks like we Slashdotted it already.

    As usual you can view using the trusty Google cache by clicking here [216.239.35.100].

    Yeah I know I know ....karma whore :0p

  • This post has been... (Score:4, Funny)

    by Kalidor ( 94097 ) on Monday April 15, 2002 @07:00AM (#3342239) Homepage
    This post has been brought to you by the Letter K and the letter V, and the number 3.
    • This post has been brought to you by the Letter K and the letter V, and the number 3.
      Shouldn't that have been:
      This post has been brought to you by the letter K, the number 4, and the letter M?

  • Matching #if ... #else ... #endif (Score:3, Interesting)

    by Pogue Mahone ( 265053 ) on Monday April 15, 2002 @07:01AM (#3342241) Homepage
    Does Vim support '%' on #if/#else/#endif yet? That's one of the things that stops me from switching from Elvis.

  • Why didn't Mr. Taco just say... (Score:5, Funny)

    by Rhinobird ( 151521 ) on Monday April 15, 2002 @07:26AM (#3342292) Homepage
    Why didn't Mr. Taco just say "in the red corner, VI and KDE, in the blue corner EMACS and GNOME, this is the MOTHER of all flamewars! FIGHT!"

  • Role reversal (Score:4, Interesting)

    by Faux_Pseudo ( 141152 ) <Faux.Pseudo@gmail.cFREEBSDom minus bsd> on Monday April 15, 2002 @07:32AM (#3342303)
    Lets look at this from the other side, the emacs side. With emacs you can have a browser in your editor. While you are at it you can have your shell and tetris and mail, news and and and. I am not here to expose the virtue of emacs but to instead ask why this took so long and what real bennies this will have. I can more than see the good of vi embeded with kdevelop but I would much rather use emacs as my IDE for its stablity reasons. Even if emacs was embeded in konq I would still rather use emacs by its self because konq has a habit of crashing on anything less that 128 meg of real memory. Why dont the vim developers work on makeing a vim with an IDE rather than having other work on embeding vim in other apps?

    Karma goes down by several points for unpopular oppinion.

    • Re:Role reversal (Score:2, Interesting)

      by lost_it ( 44553 )
      Why dont the vim developers work on makeing a vim with an IDE rather than having other work on embeding vim in other apps?

      You've just hit on the big difference between vim mentality and emacs mentality. Vim users want something small and can be used anywhere. Emacs users want something that can do anything. It's a subtle difference, but important.

      So emacs people write other programs for emacs, while vim people write vim for other programs.

      Both methods have their advantages. Choose whichever one suits your needs best, or if you can manage to remember how to use both, then use both as you see fit.

  • Cream with KVim? (Score:3, Interesting)

    by digitect ( 217483 ) <digitectNO@SPAMdancingpaper.com> on Monday April 15, 2002 @08:17AM (#3342404)
    <shameless plug>

    Easy to use Vim? Don't you mean Cream [sourceforge.net]?

    </shameless plug>
    • I tried cream just last week, the unfortunate side effect that it made the console mode vim really damn confusing, because there's no menu system with it, and maybe my remote console didn't have all ctrl keys and such working right, I'm not sure.

      But when used with gvim, it's great. It takes the "vi" out of "vim" leaving you with just, "m".

  • Oh Ned! You ARE a vi man after all! (Score:3, Funny)

    by jdfox ( 74524 ) on Monday April 15, 2002 @08:26AM (#3342429)
    http://www.darryl.com/vi.shtml [darryl.com]

  • For GNOME... (Score:3, Interesting)

    by reynaert ( 264437 ) on Monday April 15, 2002 @08:26AM (#3342431)
    There's a similar project for GNOME, called Gnome-vim [opensky.ca] (screenshot [opensky.ca]). AFAIK, it is only useable with Evolution.
  • Finally a good reason to try KDE.
  • "the power of VIM with KDE's friendliness"

    What do you get then? Something that is almost user friendly?
  • User-friendly VIM! I can't wait! Nothing sounds kludgely like a mouseless text editor with mouse support!

    *sigh*

  • Is this "innovation"? Think again. (Score:4, Funny)

    by bhorling ( 42813 ) on Monday April 15, 2002 @08:54AM (#3342541) Homepage
    I'm highly suspicious of this "integration" process. This uncessary addition of vim into KDE will deprive consumers of real choice, potentially leading to a stranglehold in the up-and-coming field of text editors. Will retailers have the option of replacing Kvim with a component of their own choosing? What will happen to the Kemacs, Kpico, and the just-started Ked projects? I've read before that KDE has not been developed with modularity in mind, making Kvim's removal impractical at best, so we may be witnessing a thinly-veiled attempt by KDE to subsume the entire editor market. Before we jump on the bandwagon here expousing the virtues of this marriage, we should take a lesson from history and recognize the many subtle consequences of this action.
  • There are two ways to get vi / emacs / your-favourite-editor embedded into konqueror or kmail or whatever. Either make it into a 'component' which visually sits inside the konqueror window, or write a lightweight component which calls out to a separate editor process. Think about Emacs's 'server mode' where you set $EDITOR to 'emacsclient' and your currently-running Emacs is used as an external editor.

    You could have a KDE editor component which just displays the text and a big 'edit' button; the button when pressed launches $EDITOR, which could be Emacs or whatever. It wouldn't look as nice as embedding kvim directly into the app's window, but it should work with all editors, with no special KDEification needed for each one.

  • Great! (Score:4, Funny)

    by Dwonis ( 52652 ) on Monday April 15, 2002 @09:05AM (#3342597)
    Now how long until we get KDE for Emacs?
  • The article talk about embedding Vim in Konqueror. Unfortunately, I can't reach the site to read the details (/.ed), but if that mean I can use Vim in textbox (such as the one typing in right now), then I am really excited.

    That will double my productivity when posting to /. :)
  • I can finally leave Visual C++ behind. I hate the platform but love the ide and the syntax highlighting, font support from the built in editor even though the macro support sucks compared to vi or emacs. The built in editor in kdevelop sucks sucks goat balls and is close to unusable. No smart indenting, bad font support, no quick commands like dd to delete entire lines or space folding like VIm. I know in unix version of VIM you can just do a :make projectname inside gvim itself but I miss the built in debugger, as well as the docs in Vstudio. For example when you have a snytax error in VC, the debugger just goes to the appropriate line so you can fix it. Using a seperate program just tells you the line number and you have to move to the line yourself to fix it.



    It seems odd in the early 21st century to be using only an editor and nothing else to do any real development work. I hate launching ddd, GVim, and kdevelop seperatly for coding, debuging, and looking up documentation. My solution was to enhance my coding skills a little more and actually write a version of Vim and litteraly call it Kvim and then try to use kparts to integrate it with kdevelop. Exactly like what these guys are doing. They beat me to it. Oh well. It would of looked good on my resume. Anyway I will be the first to download it and try it out. This is a must needed godsend for unix and linux. Its hard to convince people to switch when using old command line editors from bash like vi. ALso the unix approach to a problem is to have alot of smaller programs that do one thing well and to use them all together. vim and kdevelop fullfill this idea well.

  • Licensing problems? (Score:2, Insightful)

    by SLi ( 132609 )
    From the KVim page:

    KVim is released under the smae 'charityware' licence as vim. Please see the vim website for more info.

    Why do I smell licensing problems here? That is, unless the developers have a commercial Qt license, they are required to distribute any software linked with Qt under the GNU GPL.

    I believe that would be the second time, as Vim was previously linked with libgpm (I don't know if it currently is), which is also distributed under the GNU GPL.

  • /.ed already.... (Score:2, Funny)

    by Anonymous Coward
    /.ed already.... Looks like they should have been using IIS.

    Silly rabbits never learn...
  • I'm a KDE user and a GVIM fan, so this is absolutely great. I use GVIM under Windows as well, which helps me keep some unity and sanity to my text editing. I particularly love the search and replace power of Vi (basically full sed scripts, inline) and often spawn it from VC++ to do complex searches-and-replaces. I've read that you can replace the VC++ editor with GVIM using OLE, which I might try too.

    I do like Konquerer's file manager mode (Mozilla is much better IMO for the web), particularly the CLI attached to the bottom of the window. In fact, I often use it to spawn GVIM to edit a file... Being able to bring up GVIM inline to do text editing would be a dream.

  • KVigor? (Score:2, Funny)

    by CptNerd ( 455084 )
    Vim for KDE, does this mean someone will port Vigor to KDE? KVigor?
  • The one thing I hate about vim/gvim is the inability to do MDI. I want to be able to edit multiple documents at a time and copy/paste text between them. The split window just sucks. If you open two separate vim windows, then the only way to copy paste is with the mouse. Then there is some funky way to cycle between open files in the same window, but then you actually need to save the current file and open the next one. All of these methods suck. So, is there or are there any plans for a *real* MDI in vim? I'd like that even more than KDE integration.

  • Names (Score:5, Funny)

    by Snafoo ( 38566 ) on Monday April 15, 2002 @12:03PM (#3343635) Homepage
    I think we're going to witness the developmental evolution of KDE application naming.

    Simply prefixing the program with the letter 'k' is not enough, as those lamers developers over at Gnome can simply take the same program, s/qt/gtk+/g, and s/^k/g/g. How's a KDE developer to cope?

    Here's an idea: Give all KDE apps girl's names. We have Kate; now all we need is Kim, Kamilla, Katherine, Kookie, Koko, Kitty, and so forth.

    Gnome will no longer be able to follow. Aside from 'gertrude', there aren't that many female names beginning with the letter G. And in any case, what are they going to call 'gnome-kate'? Gate? Gkate? Gnate?

    Mwahaha! Now all we need is a non-crashing build of KDE3.0, and we shall rule the world!

  • Does this remind anyone else of the Parrot (Python + Perl) joke? In particular, the joke sample code they produced?

    Quoting from the joke:
    # copy stdin to stdout, except for lines starting with #
    while left_angle_right_angle:
    if dollar_underscore[0] =eq= "#":
    continue_next;
    }

    -Paul Komarek
    print dollar_underscore;

  • I read about the embedding in Konqueror but couldn't get specifics because of the slashdotting. Here is an idea that I have for a potential use of kvim:

    I use SquirrelMail [squirrelmail.org], a web-based IMAP client, to read and send mail. It would be super cool to be able to use kvim in place of the usual browser-provided TEXTAREA editor when I send mail. This would also work well here on slashdot, for editing comments like I'm doing now.

    Chris

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close