Feature list for 4.0

[Andreas Pakulat]

On 18.06.08 16:42:43, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > It actually really is, besides being a bit slow on my machine in general
> > (mostly thats kate's fault though). Quick-Open does work quite well
> > already, including all project files and classes. BTW: I suggest to only
> > turn on "Project" scope in quick-open, thats a _lot_ faster than if you
> > have "included files" and the other option on (which IIRC is the
> > default).
> 
> Will make a note to check, but my "project" is still nearly the size of 
> kdelibs, and I *need* quick-open to work on all of that.

I was about to open kdelibs today, but didn't get around to it. I'll
probably have a try on that the next day as I need to fix global
shortcuts myself as it seems :(

> > Thats the project tree. I don't see a comeback of the general purpose
> > file-tree we had in kdevelop3.
> 
> That's... unfortunate, given I still have several complaints about it 
> relative to file tree. No bolding of project files

The project tree by definition only shows project files. That is,
whatever the projectmanager considers to be project files. I guess
you're using the "Generic Project Manager", which basically just adds
all the filesystem gives to the tree. But sooner or later I'm planning
to make that equal to the "custom makefile project" stuff in Kdevelop3
(so you can better define whats part of the project).

>, no hiding non-project files,

We're planning on supporting some filtering (already have a proxy model
in place), but am not sure yet how fast that will be on larger tree's

> not horizontally scrollable,

See below.

> needs an extra indentation level,

See below.

> keeps wanting to eat up 1/3 of the vertical space with a pane I don't
> need at the bottom...

See Below :)

> ...or add those features, along with the ability to expand folders 
> in-place, to file system.

That one is a wontfix. I find the filesystemview highly unusable -
though pretty cool for "show effect". I like to have an overview and
being able to quickly switch between different subtrees in multiple
projects. Without going 4 levels up and then 6 levels back down.

> Actually I think that would be better, because 
> you can "root" it wherever works best.

We'll certainly have more synchronization between project treeview and
filesystem. The problem here is that we somehow managed to get us into a
"trap", you can actually have more than 1 project tree view and more
than one filesystem view, so which should one synchronize :) IIRC I've
recently talked with Hamish or Vladimir about possible solutions for
that, but no code yet :)

> Right now the ability to navigate files feeels noticeably worse than in 
> 3.x. Maybe eventually quick open will compensate for that, but quick 
> open isn't there yet either.

/worksforme :)

> >> As I said, project view is halfway there... I can live with the 
> >> sort-by-type, 
> >> but the extra indentation 
> > 
> > ?? What indentation do you mean?
> 
> The top-level is "default" (I guess that's the project name or build 
> configuration or something).

Thats actually your "workspace". Its a place where non-project-related
configurations and data's are stored, which nonetheless shouldn't go
into $HOME/.kde4/share/config/kdeveloprc. For example teamwork plugin
will need this. I'm probably going to either hide it completely, or only
show it on request as it doesn't really add any valuable information in
the project tree.

> The folders under that are indented one level, where they weren't in
> file tree. Maybe that's needed by the view, but it's still 2-3
> characters wider I have to make the pane.

The view is just a plain QTreeView, it doesn't need that. Its the model
that creates the extra item.

> >> and lack of horizontal scrolling 
> > 
> > Hmm, my projectree does have horizontal scrollbars. Did I miss
> > something?
> 
> Got me... My project view certainly has no horizontal scroll bar, and as 
> a result likes to truncate file names. I'd attach a screen shot, except 
> I'd have to either make a KDE project first (don't have any kdevelop4 
> projects for KDE yet) or else go through a bunch of effort blurring 
> names... Let me know if I should do one of those, though.

Yes, a screenshot would help.

> >> are sub-optimal. Plus it has that lower pane that insists on sucking up 
> >> valuable space.
> > 
> > Check out the little green arrow, yes that one you're looking at now.
> > Try to click it and voila the buildset stuff is hidden.
> 
> Yeah, I know. Would be nice if kdevelop would remember that I don't want 
> to see that :-).

In theory that sounds good, unfortunately there's a slight
implemenetation problem (I just tried): All project manager views would
share this setting -> BAD. Especially as there are already two view
instances created during startup and one of them is then deleted without
ever being shown, so the stored setting would always be overwritten.

But its on my todo list :)

> >> Project view doesn't seem to have this either??)
> > 
> > For now the project managers add all files in the directories to the
> > project tree, so everything you see in the project tree belongs to the
> > project. The problem is that at least cmake and mostly also plain
> > Makefile's don't have enough information to properly add the header
> > files of a project to the projecttree. This means you won't have
> > quick-open on it and possibly some more problems. Besides the
> > projecttree looks rather funny with "just" dirs+targets+cpp files.
> 
> Ouch. 3.x with manually maintained file lists was much better here, 
> especially for esoteric build systems (or even e.g. cmake that's not 
> well handled by the built-in project managers).
> 
> In case you haven't guessed, I hardly used the project manager stuff in 
> 3.x; not for the main projects I work on, anyway.

That what the generic project manager is for, but its got close to 0
attention. I'll be working on it though as soon as I can use Kdevelop4
at work, because we also have a custom buildsystem which I don't really
want to integrate into kdev4... And I'm pretty sure it'll work more or
less like custom makefile support in kdev3.

> >> 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.
> > 
> > Your build is old ;) That doesn't happen anymore - or rather it should
> > not. Hamish keeps saying it happens for him, but I can't reproduce that
> > anymore since I removed a few uneeded methods from the treeview.
> 
> I didn't realize 24 hours was "old" already? I updated and built my 
> entire KDE tree, from support to kdevelop, last night (unless it's 
> qt-copy that changed?), and I still see the problem in an instance I 
> started after I began typing this reply.

:( I fear than somebody else needs to look into this, it doesn't happen
here anymore and I'm not aware of changing any setting in the
meantime... 

Andreas

-- 
Give thought to your reputation.  Consider changing name and moving to
a new town.