[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Some questions regarding development for KDE3
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2007-01-18 19:43:23
Message-ID: 20070118194323.GA3588 () morpheus ! apaku ! dnsalias ! org
[Download RAW message or body]

On 18.01.07 18:44:20, Guillaume Laurent wrote:
> On Thursday 18 January 2007 12:47, Andreas Pakulat wrote:
> > On 18.01.07 10:53:40, Guillaume Laurent wrote:
> > > That said, Kate's "indenter" is still a joke, it's barely existent. It
> > > merely consists of being able to insert tabs at the beginning of several
> > > lines at once, nothing more.
> >
> > Hmm, my kate can insert tabs or spaces nearly everywhere in a line, but
> > auto-indentation inserts at the beginning of the line.
> 
> Indentation has to be at least minimally aware of the language syntax and 
> perform some basic parsing in order to know how to indent things. Kate's 
> indentation appears to be completely braindead.

Last thing I heard is that kate uses regexps to "parse" the language at
hand, which of course fails in quite some cases, especially on complex
languages like C++. And it does work for me more than 70% of the time
with spaces, it does not work at all with tabs here.

> > > Even the one in Eclipse CDT, as primitive as it is, still
> > > works better, but the best remains Emacs by far (at least when it comes
> > > to C/C++ - for Java it's Eclipse again).
> >
> > Sorry, but eclipse CDT is a joke in itself.
> 
> Two of the main RG devs (me being one of them) have been using it quite 
> happily for several months now. It still has many shortcomings (the main one 
> being resources), but it still the best tool I could find for the job at the 
> moment. Only the version released with Eclipse 3.2 is useable though, the 
> previous ones were jokes indeed.

I guess my testing sessions were too short :)

> > > (while I'm ranting on Kate/KDevelop, did they still have this useless
> > > 'class tree' which shows every single class of the project as the sole
> > > mean of navigating through classes ?)
> >
> > No idea what version of kdevelop you tried, but we now have at least 4
> > methods of navigating through classes: the class view (with a sync-to
> > file option), the navigation bar, the quick-open and the project manager
> > (which is more for files, but often it is 1 file == 1 class). And I can
> > jump around classes very quickly.
> 
> kubuntu only offer 3.3.4, no way to install the 3.4 RCs yet. Forgive me if the 
> improvements you're talking about are in 3.4 only, but I just gave 3.3.4 a 
> try, and it's still not useable :

Yes, 3.3 is not good at all. There should be debs for Debian Etch and xUbuntu on
http://software.opensuse.org/download/home:/amilcarlucas/
sometime tomorrow. 

Also its not a great problem to install kdev3.4 into your $HOME, except
it takes compilation time ;)

And to make a final note: 3.3 development is dead, so don't expect
3.3.5 or 3.3.6 to be any better.

> - Quick Open Class still doesn't handle wildcards ('*'), it only completes on 
> the beginning of the fully qualified class name. How convenient when all your 
> classes are under a specific namespace, you have to type the whole namespace 
> name before being able to filter anything.

When I type "AST" on kdev4 sources I see both unnamespaced and
namespaced classes.

> - Quick Open Method is equally useless for the same reason above, it doesn't 
> even indicate which class each method belongs to.

That has been fixed in 3.4 for sure.

> - same lack for Quick Open File, which also only shows source files and 
> makefiles

It shows all files that belong to the project, if for some reason a file
doesn't belong to the project kdevelop can't do much.

> - still no outline view for the currently opened file (no, the navigation bar 
> listing all files method is not an acceptable substitute though it's a 
> definitive improvement)

3.4 can sync the class view on the left side with the current file which
gives you something that gets as close to an outline as kdev3 can. Also
the navigation bar does provide completion in 3.4

> - class view a little bit better since it's hierarchised based on the file 
> hierarchy, but still useless

What exactly is the problem here?

> - 'Find in Files' merely calls /usr/bin/find ?? You've got to be kidding here, 
> I suppose it's just a temporary fill-in until the real feature is done. And 
> it doesn't keep the previous searches in memory. The results are shown raw 
> with only basic fontification (no tree structure as you would expect), and 
> they aren't highlighted in the editor either.

You can click on any result (or use keyboard) and immediately jump to
the exact position in the given file. You see the full filename. All 3.4
though, I don't have 3.3 installed here to check.,

> - tried code completion on a trivial case (QRect var), nothing. It works on 
> Eclipse (although it takes way too long to respond)

Forget code-completion in 3.3, its broken. 3.4 is completely reworked
here. From Eclipse all I hear is that it crashes or hangs your system
when you have code completion for kdelibs or qt.

> I could continue but that would be pointless, Eclipse is a vastly larger 
> project than kdevelop with way more dev resources.

Yes, thats correct and with a firm that invests quite some money. Of
course there are things they do better, but eclipse is too darn slow
here on my system. Even typing in the editor is a pain.

> Sorry, CDT might be a joke to you, but despite its shortcomings, the only 
> advantage kdevelop seems to have over it is faster parsing and the ability to 
> show basic parse errors (something I hope CDT will provide soon).

Well, looking at 3.4 I think there are a few more things, but as I said
above I didn't have the time yet to do exhausting testing with cdt. The
stuff I tried worked not that well (and I did have 3.2, it was around
christmas last year).

Andreas

-- 
You will stop at nothing to reach your objective, but only because your
brakes are defective.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]