Feature list for 4.0
mw_triad at users.sourceforge.net
Wed Jun 18 19:59:48 UTC 2008
Hamish Rodda wrote:
> On Wednesday 18 June 2008 11:58:03 Matthew Woehlke wrote:
>> grep: where are you? I can't find the find+grep integration anywhere
> Same as kdev3, it's edit->find in files, or ctrl+alt+f. if you can't see it,
> your plugin loading is broken and you should look into why your syscoa can't
> see them.
Ok, let me rephrase that then. Please bring back the /context menu/ :-).
(I never invoked grep from the menu, always from right-clicking on
something I want to search for.) Jump to Function and friends are also
> We're working hard on the quick open stuff. It doesn't work across the whole
> project because the persistent duchain is not written... patience needed here.
I can be patient :-). I'm just saying that, with ctags MIA and quick
open not yet "up to snuff" I'm not ready to call that "releasable",
since it's a pretty big hole in function. Don't get me wrong, I
understand that there's a lot of work to do (and I'm impressed with the
progress so far!), it's just when I see Matt asking "why can't we
release" that I go "you're kidding, right?" :-). (Ok, I guess kdevelop
as-is is /functional/, just missing some important bits that 3.x has.)
>> file tree: I'd really like this back, please :-). I've been making do,
>> more or less, with the project view, but that adds several levels of
>> indentation to all files, so that I have to make it wider just to read
>> the file names.
> View-> add toolview -> file system. Yes, I think our new tool view management
> system is a problem, it's too hidden and with inadequate defaults.
Er... no, that's file list, which I hated just as much in 3.x. I need my
tree :-). For the project I mainly work on, file list (or as it's now
called, "file system") is much too clumsy. Poking around foo/bar/*.c and
needing to open foo/none/meep.h or dog/cat/pig.c is the norm.
As I said, project view is halfway there... I can live with the
sort-by-type, but the extra indentation and lack of horizontal scrolling
are sub-optimal. Plus it has that lower pane that insists on sucking up
As alluded, this project has a LOT of files in a rather inefficient
organization. File tree was adequate for dealing with it, project view
marginally so, and file list / file system not at all.
(What might work, and would be effectively the same thing, is if file
system let you expand subfolders in place. It's also missing bolded
files when they belong to the project, and the ability to hide
non-project files, or add files to the project. Project view doesn't
seem to have this either??)
Oh, and the way project view tries too hard to keep the selection
visible is REALLY annoying :-). Try to dig out a file somewhere well
off-screen of the current selection and you'll see what I mean.
>> MEMORY USAGE has gotten *waaay* out of hand. The newfangled code parsing
>> stuff is shiny, but needs 1.4 GB for *three files opened*?! To quote Ed
>> Harris*, "Gentlemen, that's unacceptable". I've already had to switch
>> computers because of /3.x/'s memory hogging... I thought Linux was
>> supposed to disobey Wirth's Corollary :-).
> Will improve much with persistent duchain and other optimisations, come back
> after SoC (that is, I presume you were already using svn head?)
Yes I'm using trunk (everything KDE on this box, in fact, is trunk).
Anyway thanks for the update, just so long as it's a known issue, that's
good enough for me :-).
Andreas: I assure you 1.4 GB is an accurate number. With the same three
files in a /fresh/ instance (i.e. just opened, haven't done anything), I
have just south of an 800 MB footprint. As David notes, I'd probably had
maybe a dozen files open in the session that had 1.4 GB, and that's a
*small* number of files to go through in this project.
I'm glad the new box is 64-bit; if I was trying to use kdevelop in its
current state on a 32-bit system I'd almost certainly run out of address
Not freeing memory from parsing sounds like a showstopper, that *will*
exhaust address space on larger projects, if not in general than
certainly on first converting to kdevelop4. Not a good first impression :-).
For perspective, the project these numbers come isn't much smaller than
kdelibs, which itself weighs in at (counting ONLY *.cpp) 1668 files and
over 650k lines, with the important trait that I tend to hit a much
larger percentage of the total than I would with a KDE project. (I also
have an 11k line file that I have to work with occasionally. Yes I know
it's insanely big :P.)
Time is an illusion. Lunchtime doubly so. -- Ford Prefect (Douglas
More information about the KDevelop-devel