Project loading (Was: KDevelop 4.0 Release)

[Aleix]

On Sun, Sep 7, 2008 at 11:22 PM, David Nolden <zwabel at googlemail.com> wrote:

> Am Sonntag, 7. September 2008 22:54:48 schrieb Aleix:
> > > What I'd like to have in KDevelop4:
> > > - Faster CMake parsing, or even better disk-caching of the results
> >
> > I'm not really sure being faster on project loading should be a big
> concern
> > for the .0 release (I'd better prefer to have it fully working, which is
> > mostly for now).
> > Said that, saving the ProjectItemModel's tree might not be that hard...
>
> Well, the problem is that we can have multiple projects, currently I have 4
> loading on every startup, and while it does go relatively fast until they
> are
> loaded, I always have to wait for it. But KDevelop4 in its base, especially
> the whole cpp support stuff including quickopen etc., nearly do not need
> _any_ load time to be functional. Since we're competing with Eclipse, we
> could make that a big advantage: A development-environment that is
> light-weight with nearly instant startup time.
>
> I would like KDevelop4 to be light-weight, like a much more powerful
> drop-in
> replacement for kate, where the user doesn't have to think whether he wants
> to take the overhead of firing it up.
>
Maybe the problem here is opening projects on startup.

Even if we cached the project model, we would have to parse in case the any
part of the project has been modified.
Needless to say that this would make the behaviour more difficult to track,
note that the cmake support relies on the system configuration (e.g. for
checking env variables, configuration files, etc.)

>
> > I would add as well incremental parsing for c++ since you said it would
> be
> > straightforward and it is a pitty when you are writing and have to wait
> for
> > the editor to write it down.
>
> I have that problem in focus. However incremental parsing would just be a
> workaround, and isn't directly related to the problem. First the real
> problem
> will be fixed(short GUI lockups due to thread locking stuff), then the
> parsing will be made more efficient, and then comes incremental parsing, in
> that priority order.
>
> Greetings, David
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080907/b22c5ffa/attachment.html>