KDevelop 3.0 Now Developer-Ready
Saturday, 7 April 2001 | Numanee
Bernd Gehrmann writes: "As you may have noticed, the HEAD branch of KDevelop now contains Gideon which is very near to being usable and complete. This is not just another version of KDevelop, it's a big step forward: it's modular, it's extensible, it can support multiple languages, it has a project management feature that is usable for non-trivial projects. Gideon can be thought of as a a modular lego-like framework for an IDE that could be used to build a C++ IDE, a Python IDE, or even a web development platform. A complete C++ IDE is already in place." Gideon is the codename for KDevelop 3.0 and is already highly usable. This is your chance to get involved whether by contributing plugins or new features such as Python scripting. For more details, you can also check out Bernd's initial email as well as the screenshots (1, 2, 3, 4, 5). Note that KDevelop 2.0 is still based on the KDevelop 1.4 branch and is scheduled to ship with KDE 2.2. Update: 04/07 02:04 PM by N: According to KDE hacker Richard Dale, Gideon now also includes Java and Objective-C support.
Comments:
Re: KDevelop 3.0 Now Developer-Ready - Henrik A - 2001-04-07
KDevelop is a nice enough IDE but the editor is severely lacking IMHO. I mean.. project handling, integrated docs and class browsers are all nice, but most of the work when programming is still typing. This is why i'm still sticking with emacs - mainly because it idents the code the way i want it without me having to fight it. Will Gideon have something more of powerful editor? KWrite is severly lacking for programming.. kwrite vs emacs is like wordpad to word (in the windows world). I have nothing against kwrite, it's a fine editor - but not tailored specifically for programming. -henrik
Re: KDevelop 3.0 Now Developer-Ready - Roberto Alsina - 2001-04-07
Perhaps you want to check KFTE? It's a very nice programmer's editor, if I may say so myself :-) Currently it can't be integrated into kdevelop, but I think I know of a way to achieve it. Maybe.
Re: KDevelop 3.0 Now Developer-Ready - ac - 2001-04-07
I tried it out... it rocks :-)
Re: KDevelop 3.0 Now Developer-Ready - Bernd Gehrmann - 2001-04-08
Does it support multiple views per document? Does it support breakpoints? Of course, you could integrate any other editor, including kfte. But without these features, you will lose quite some functionality.
Re: KDevelop 3.0 Now Developer-Ready - Roberto Alsina - 2001-04-09
Multiple views per document? Yes, but it's broken :-) Breakpoints? That's a debugger's job ;-) I was comparing it to kwrite, not kdevelop as a whole. Right now, I am working on a DCOP interface to KFTE's guts, so it will be "integrable" into kdevelop eventually, and everyone will be happy ;-)
Re: KDevelop 3.0 Now Developer-Ready - Bernd Gehrmann - 2001-04-09
I understand that you were comparing it to kwrite. My point is that 'making everyone happy' is probably a bit more complicated than having a couple of commands like 'open file foo.cpp'. For example, on a monitor less than say 19", you will want to coordinate window management between kdevelop and the editor, otherwise half of the time the editor will cover your documentation or error message windows, and half of the time the kdevelop windows will cover your editor (aka the 'gimp effect'). As for breakpoints being the debugger's job I assume you know that kdevelop's debugger uses kwrite for displaying source code? :-) When people use the integrated debugger, I assume they want to use the source display for editing files immediately. Otherwise the point of an integrated debugger looks quite moot to me. OTOH, the only debugger commands I ever use are run and bt, so maybe I'm the wrong person to discuss this ;-)
Re: KDevelop 3.0 Now Developer-Ready - Roberto Alsina - 2001-04-09
KFTE will have an embeddable view. The plan is to make a fully fledged kpart. Precisely because of the gimp effect :-) About the debugger stuff... well, I suppose it's just a matter of providing the same interface KWrite does. Since the exposed functionality of FTE's EBuffer class seems to do all that and some more, I don't see a problem. It's just a matter of work :-) Making KFTE a KPart, on the other hand, requires some thought, which is why I say it is a plan, right now :-)
Re: KDevelop 3.0 Now Developer-Ready - n/a - 2001-04-07
Maybe people already know if it, but what about scintilla (<a href="http://www.scintilla.org/">http://www.scintilla.org</a>)? I don't know how much it would take to integrate it, but I think that thekompany is using it for blackadder, activestate is using it for komodo. it has auto-indent, code folding, lots of lexers, and is fast...
Re: KDevelop 3.0 Now Developer-Ready - Shawn Gordon - 2001-04-08
We're going to release our port of Scintilla to Qt shortly. We are just coordinating with the scintilla group. We also ported it to BeOS, QNX and AtheOS, so there is a bit to organize.
Re: KDevelop 3.0 Now Developer-Ready - Wolfgang - 2002-08-01
Shawn, when is soon? I've seen several announcements from TheKompany that this is going to happen any time now. Would be nice if it really happened.
Re: KDevelop 3.0 Now Developer-Ready - Henri - 2001-04-08
I fully agree with you. Emacs might not be the nicest editor, it's still the most powerful and when you start programming, why would you not choose the best editor ? The way "Tab" works is really fantastic ! KDevelop is nice, help etc. is cool but I still use Emacs (though it's really Esc Meta Alt Control Shift so you'd better use it daily to remember all key comibnations). Something between Emacs and Borland's Builders (class completion, help, on-the-fly compilation for JBuilder: as a friend says, nowadays processors really allow that) would be the best.
Re: KDevelop 3.0 Now Developer-Ready - robert - 2001-04-07
KDevelop is nice, but an editor that can do auto-indention and code-insight stuff would be about 100 times cooler. I'm not realy sure how the progress on Kvim is but alot of work is being done to have Gtk and Qt use the same message loop and gvim works perfectly, and that means that since XEmacs is going to switch to Gtk that XEmacs could be used as an editor as well. Also for code-insight stuff, I once wrote something like that for Gtk but I deleted it some time ago, if I ever re-write it I'll probably mail it to one of the KDevelop people, and I'd be happy to help write one for KDevelop if it has little dependancy on Qt(I'm not a particular fan of the GPL either).
Re: KDevelop 3.0 Now Developer-Ready - Dan Smart - 2001-04-07
XEmacs is not going to <B>switch<B> to Gtk. Gtk is now one possible widget set that you can compile XEmacs to use. Work is I believe either in progress or soon to start on a Qt/KDE binding for XEmacs.
Re: KDevelop 3.0 Now Developer-Ready - ac - 2001-04-07
Yes, and it is not even a stable or recommended port. I strongly believe "robert" is an incoherent troller. Like he wrote a code-insight editor in Gtk and then threw it away. Like he will write a new one and mail it to KDevelop developers. Right... Best to ignore him. I don't understand why these trolls don't stay on the GNOME site.
Re: KDevelop 3.0 Now Developer-Ready - robert - 2001-04-07
There was alot of talk about changing XEmacs to use Gtk by default on X, there's a Gtk port as well, Gtk and Qt will be in the same message loop soon that means that Qt programs will be able to use Gtk widgets with much less overhead, as far as I know the Gtk port is further along with vim and Xemacs, it's stupid to not use something because of the toolkit it's based on, the power of open-source is that the code is allready there. Also this code-insight editor is not all that hard to write, just do this: Have a bunch of structs like var_t type_t function_header_t That have there positoins on the text held by int pointers that are maped to a list of int's that get updated with text mutations(like if I insert a char go to that point and incriment all the values, if text is deleted decrement some values and update alot of your variable data stuff(keep reading)) and have them also hold a bunch of info like the acessor(public, private etc) and what the real type they are(strip out stuff like auto etc). Then write a nice parser that works with std::string's that first cleans comments and macros out of the string and get's rid of extra spaces, the parser can then seperate the words getting rid of problems like ' std :: string' is one word, from there it's easy to find functions, var declerations and such, when you get the decleration take the type or the return type and get the actual type(clean out words like auto const and such, that way if the type is a class you can look that up). Then make a class like scope_t and give it a virtual function like parseline, have maps that map strings that are variable and function and types names and such to there coresponding structs, also the have pointers to the children scopes. Make classes like class_t and namespace_t and have them extend scope_t, scope_t should also have something like base_parseline, that takes care of getting the acessors right and such. Then make a struct called something like scope_lookup_data that has the stuff that the code insight shows, this should take a parameter that can be passed that shows the acess type('::', '->', '.') and the part of the word allready typed, this function should also be virtual. Then have a queue that holds the lines that were changed(there can be all sorts of optimization to make sure the same line dosen't get queued a bunh of times). Then have a global var thats a scope_t named something like scope_in, if a line is found that has something like the beginning of a class definition then you should have a list of children pointers in the scope, set one of them to a 'new' scope and set scope_in to new scope. I'm sure I forgot some stuff, the reason that I deleted it is because it only took me like a week to write, and I didn't work with any editors or IDE's so it was pretty useless, plus VisualStudio and SlickEdit work fine for me. Also the reason that I used Gtk is because I don't like the GPL, if I did give it away it would be under a BSD type liscence.
Re: KDevelop 3.0 Now Developer-Ready - anon - 2001-04-07
Don't worry about XEmacs. It's okay, but most people use it only for the identation and because they have spent ages customising it. Why don't you try out: <br><br> <a href="http://devel-home.kde.org/~kate/">http://devel-home.kde.org/~kate/</a><br> it's the new Kwrite. <br><br> Also KFTE... it's very good. <br><br> Kvim is being developed... but (I think) it is not being ported to QT, it's instead being turned into an XPart. Should be cool once it's finished. <br><br> You seem to know what you want, maybe you could help out on one of these projects? :-) If you don't like QT because it's GPL, well, that's no problem since it's also under the QPL licence, so no worries releasing code linked to QT if it's under a BSD style licence.
Re: KDevelop 3.0 Now Developer-Ready - Anon - 2001-04-07
Hmm, XEmacs has *all* features listed on the Kate page and about a million more. I think I'll switch to Kate _right now_...
Re: KDevelop 3.0 Now Developer-Ready - anon - 2001-04-07
I meant to say that there are alternatives if you use XEmacs just as a simple editor. Of course, if you use those million features then stick with XEmacs :-)
Re: KDevelop 3.0 Now Developer-Ready - ac - 2001-04-07
If you would like to be productive, why not stop your trolling and fudding? You seem like a reasonable guy. So why do you perpetuate myths that you can't release code under BSD for Qt? The KDE project does it all the time. Just go read the licenses, and ask rms@gnu.org for clarification if you cannot understand the GPL. English can be a tricky language, especially legalese. And what is this message loop crap you talk about? Don't you realize your vaporware talk helps nobody?
Re: KDevelop 3.0 Now Developer-Ready - robert - 2001-04-07
I'm sorry if I said something wrong, I don't use linux and I just started working on some stuff with KDE and GNOME about a month ago, I'm not real familiar with all the stuff. Also there will eventualy be a merge of the Qt and Gtk message loops, this wont effect develops becuase Qt and Gtk both use signals.
Re: KDevelop 3.0 Now Developer-Ready - KDEBoy - 2001-04-07
All that needs to be said here is ... bullshit baffles brains. He doesn't use Linux but has already written a GTK project, and thrown it away? He then right that he is not familiar with "all the stuff". And his last sentence is an absolute gem as well. robert, go away, now!
Re: KDevelop 3.0 Now Developer-Ready - AC - 2001-04-07
Actualy the thing about the message loops is true.
Re: KDevelop 3.0 Now Developer-Ready - robert - 2001-04-07
I use Solaris OE, GNOME and KDE both run fine, I've never used linux before though.
Re: KDevelop 3.0 Now Developer-Ready - Kuba Ober - 2001-06-12
KDEBoy is suffering from mind bias, but that's understandable. not-Linux doesn't imply not-KDE ;-). What robert says is 99% right, no need to attack him. Message loop merging is being worked on, and there's nothing fantastic about it. That's what windowless controls in Windo$e do all the time (sort of, indirectly), no big deal, even crappy M$ programmers do it. robert is OK with me, I'd say. Only those people who look deeply into the future are making the progress. I presume KDE founders were accused of trolling or making-useless-things a few times in the history as well. Arguments like `Oh but why another desktop environment' and `better concentrate on Gnome' or whatever must have been raised from time to time. This is a discussion forum that, to my understanding, is meant to promote flow of ideas. One can really make a big piece of code in one week. Just because M$ Visual Studio takes so many megs to do simple code-insight editing doesn't mean it cannot be done in about 6000 lines of code, with similar efficiency. My coworker, sitting next to me, ported a Windows realtime data display application (written in API, no MFC), to Qt on Linux in 2 days. That was about 3000 lines of code. At the end of 2nd day it worked flawlessly. That's just an example. Another is porting mozilla to Qt, which took one mythical-man-month. There's no way I'd ever dare not to believe robert about what he did. Myself I threw out and/or abandoned lots of code. I had a simple statistics application for hand-made measurement processing, that was about 15000 lines long and it was in Pascal for DOS. I still have it somewhere, but it's one copy on one floppy somewhere. For practical purposes it's a work thrown away. I'm nearly sure that in my life I abandoned about 50000 lines of code in several projects, most of them were quite useful. I'm 25, if that matters. Cheerz, Kuba
xemacs/gtk not stable? - Thomas Stromberg - 2001-04-08
I've run xemacs/gtk since September, and have not suffered a crash since November. That's pretty stable to me. IMHO, it should be default, if nothing else, for the new file chooser <grin> I love xemacs too, I wish startup time was a bit faster, but with all the lispy's I need for my development, it takes a bit. Now, if kdevelop got a little farther, had some plugins for Ruby, Perl, and PHP development for me, it could definitely be a very good thing. I already use xemacs & joe, I'd hate to add a 3rd editor for just my C work. Glad to see KDevelop getting better, now my roomate no longer bitches about crappy IDE's for C.
Re: KDevelop 3.0 Now Developer-Ready - robert - 2001-04-07
That's what I meant, sorry if that sounded misleading, but the thing is that Gtk will soon use the same message loop and Qt(hopefuly) which means that overhead will be minimal and becuase of QGtkWidget it would easy to get a good editor now, and I had never heard of a Qt port of XEmacs.
Re: KDevelop 3.0 Now Developer-Ready - KDE User - 2001-04-07
Congratulations! Trust the KDevelop guys to develop two branches at once! I must say you guys really did a brave thing in deciding to put HEAD on hold and port KDevelop 1.2 to the KDE 2.x platform. Everyone wanted this and we all love you for doing it! Now we have KDevelop 1.4 a thing of beauty, next KDevelop 2.0, and then everybody's dreams will be realized with KDevelop 3.0. Ignore your detractors and forge ahead! There is a big need for this project.
YES !! - thil - 2001-04-08
Agree with you. Kedevelop 1.4 is practical and beautiful. And Kdevelop 3 look's great. Thank !!
Developer-Ready? - Justin - 2001-04-07
Clarification? So who are the developers here? I guess "users" of KDevelop are not developers in this sense, right? 3.0 is maybe ready for people to develop _for_ it, but not for people to develop _with_ it? -Justin
Re: Developer-Ready? - nap - 2001-04-07
You're about right. Only the bravest of the developers have started eating the dogfood :)
Re: Developer-Ready? - Richard Dale - 2001-04-07
Well, I've been using KDevelop (gideon) for the last week, and have found it pretty stable. There are rough edges, and missing features, but it didn't crash on me. Bernd's post above on Friday morning is slightly out of date, as since Friday afternoon KDevelop 3.0 has had Java and Objective-C support added. You need to check out the current 'kdebindings' module and build it to compile and run the Java project template. -- Richard
Re: KDevelop 3.0 Now Developer-Ready - Jesse - 2001-04-07
I havent played around with Kdevelop for a while because of the several aformentioned inconvieniences. I was wondering though if KDevelop has extensive context sensitive support and other code-helpers? Like the kind of integration you would get with Visual Assist with VC++?? Visual Assist IMHO, is a very good model to mimick, as every feature makes _every_ single task you do 10x faster and that much more usefull.
Vim support - bram - 2001-04-07
I hope we gonna get the possibility to use a vim like editor in kDevelop. Would be a nice combination I think. -- bram
Re: Vim support - bgb - 2001-04-08
Agreed. I use some version of VIM for most of my programming at work and home. I'd really find IDEs like KDevelop easier to use if they had VI-like keybindings available as options.
Re: Vim support - Michael - 2001-04-09
Right, the current editor is great for people how aren't used VIM of EMACS as they can use Ctrl+C/Ctrl+V,... But onced you tasted vim or emacs you can't live without it anymore. I really like KDevelop, because of generating makefiles, headers and so on, but for writing I still prefer vi.
Re: Vim support - Lada - 2001-05-10
I second this. CTRL-C/CTRL-V... can be real pain in the neck, so to say. I am used to vi and must say that it has multiplied my productivity when I started using it. Editor in which it is easier to use mouse to copy and paste is just not "fast" enough. :)))
Re: Vim support - celer - 2001-04-09
You might get kvim from kdenonbeta/kvim cvs. It is getting there. It could still use some more developers. Right now the interfaces for making kvim a kpart are there, but they are not hooked into kvim. Once kvim implements these interfaces it will be much closer to being able to be used by kdevelop. Other then that kvim is still buggy, but has most of the functionalty of vim. celer
Great! - Kirby - 2001-04-07
Cool! Does this mean KDevelop can be fully integrated with Gnome technologies like Glade? And what about automake/autoconf integration? I never liked KDevelop's autoconf/automake system. It caused a lot of compilation problems on other systems the last time I used KDevelop.
Re: Great! - Richard Dale - 2001-04-07
Bernd has done interesting stuff with automake. Whereas KDevelop 1.x/2.x uses its own project file to generate the Makefile.am's, KDevelop 3.0 is driven directly from automake .am files. So if you understand automake, I would say you'll like it, but on the other if you want to be hidden from it you might not. Not all projects have to be automake ones - that is just a plugin. -- Richard
Re: Great! - Felek - 2001-04-07
I'm using KDevelop only as a multi-file editor because it has its own project management ( I prefer to edit makefiles by hand ) and a horrible self-closing class-tree. Project management based only on makefiles is a great idea but what with the second point ? Does KDevelop 3.0 contain a better class-tree view ?
Re: Great! - Bernd Gehrmann - 2001-04-08
Well, it contains a better class-tree view, which e.g. properly supports classes with the same name in different namespaces. It also supports browsing the namespace hierarchy, and showing the fully class names with full scopes. Currently, it still builds the tree from scratch whenever the source info database has changed. However, there is no design problem with implementing this. I'm sure you could do it in twenty minutes.
:-D - Kirby - 2001-04-09
FINALLY! You don't know how long I've been waiting for this! :)
Does it support Emacs-like searching - Erik - 2001-04-08
The reason I don't use any KDE editor yet is that I like the Emacs-style searching. You type the word you search for and Emacs stars searching immediately. Often you don't have to type the whole word. In KDE editors you have to type the whole word i a dialog box and then search. That irritates me. Just as bad as when I used Windows.
Re: Does it support Emacs-like searching - Bernd Gehrmann - 2001-04-09
Sure, that's a feature I cannot live without :-) That's why I have implemented it for KDevelop :-)) <br><br> Have a look at <a href="ftp://ftp.kdevelop.org/incoming/gideon1.png">gideon1.png</a>
Re: Does it support Emacs-like searching - Erik - 2001-04-09
Great! :-) Looks just like in Emacs (except that Emacs puts a space after the kolon, but that is trivial) but with the superior GUI of KDE. I will definitely give it a try when it is released as stable. Did you implement this functionality in normal kwrite as well? I mean, it could be very useful when editing files in general, not only sourcecode. Or should I replace Emacs with KDevelop for allround text editing as well?
superior GUI? - Mike M. - 2001-04-09
Superiority isn't necessarily in appearance. In fact, one of the most important features of XEmacs is its set of key bindings and its window management: you can do everything quickly and efficiently from the keyboard, and windows get created and disappear with minimum intrusiveness. I think KDevelop would do well to try an emulate some of those features.
Re: superior GUI? - Erik - 2001-04-09
I was thinking about GNU Emacs and it's grotty window placement and resizing behaviour. I also hate it's undo feature. That's why I want to switch to a KDE editor eventually, because KDE applications got both these things right. I have not tried Xemacs, but I disagree that all keybindings are superior. For example that I have to press 2 shortcuts to save instead of 1 like in KDE applications.
Re: superior GUI? - Bernd Gehrmann - 2001-04-09
Sigh. Why don't you, instead of talking, just try the HEAD branch or at least look at the screenshots. Then you may come back with constructive criticism.
Re: Does it support Emacs-like searching - Bernd Gehrmann - 2001-04-09
The 'normal' old kwrite is not maintained anymore and its successor is more or less a subset of kdevelop. For use as an 'allround text editing tool', we would certainly want a little plugin manager that allows you to switch off things like the documentation tree which you don't need then and which just clutters the gui if you don't it. To the 'replace Emacs with KDevelop' I would say it depends on what you expect from an editing environment. KDevelop will certainly never compete with Emacs in terms of features which can be better implemented in a separate application. So it will certainly never be a mail reader or an eliza clone. In my experience, most (but not all) people prefer emacs because of only a small number of features which includes a) incremental search, b) scripting and c) indentation. We now have a) and a starting point for b). It would be nice if someone implemented c).
Target platform interface ? - Johan - 2001-04-09
It would be nice if it could be prepared so the it can be used as an IDE/debugger for a target platform, connected via serial bus for instance. It if was prepared for this, chip vendors would have a standard platform to write connection modules for their development boards. This would, more than anything else boost Linux as an embedded system development platform.
Re: Target platform interface ? - Bernd Gehrmann - 2001-04-09
If you and others want to implement this, you are welcome. AFAICT, none of the current developers has any idea which issues are involved here.
Re: KDevelop 3.0 Now Developer-Ready - C. D. Thompson-Walsh - 2001-04-12
Two idle things 1) Why Gideon? Just curious... 2) I'd like to register my vote in favour of strong (EMACS/ViM-style) code-editing basics. I'm sorry, but I think Visual Assist is silly :-), and only feasible in VBasic...
What would be really cool.. - Programmer guy - 2001-06-10
..would be if they would gut the code from vim to handle editing. Since most editors like vim/emacs work on buffers now anyway, how hard would it be to make a 'virtual buffer' layer that looks like a standard buffer to the original editor code but manages a editing window instead? It would sure make a damn nice KDE widget..