Feature list for 4.0

[Matthew Woehlke]

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 
missing :-(.

> 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 
valuable space.

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

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

-- 
Matthew
Time is an illusion. Lunchtime doubly so. -- Ford Prefect (Douglas 
Adams' HHGttG)