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

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.

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.

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 ;-)

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 :-)

Maybe people already know if it, but what about scintilla (http://www.scintilla.org)? 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...

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.

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).

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.

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.

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.

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?

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.

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".

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.

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

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.

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.

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.

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?

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.

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.

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.

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.

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.

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 ?

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.

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.

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?

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.

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.

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).