<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Sep 7, 2008 at 11:22 PM, David Nolden <span dir="ltr"><<a href="mailto:zwabel@googlemail.com">zwabel@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Sonntag, 7. September 2008 22:54:48 schrieb Aleix:<br>
<div class="Ih2E3d">> > What I'd like to have in KDevelop4:<br>
> > - Faster CMake parsing, or even better disk-caching of the results<br>
><br>
> I'm not really sure being faster on project loading should be a big concern<br>
> for the .0 release (I'd better prefer to have it fully working, which is<br>
> mostly for now).<br>
> Said that, saving the ProjectItemModel's tree might not be that hard...<br>
<br>
</div>Well, the problem is that we can have multiple projects, currently I have 4<br>
loading on every startup, and while it does go relatively fast until they are<br>
loaded, I always have to wait for it. But KDevelop4 in its base, especially<br>
the whole cpp support stuff including quickopen etc., nearly do not need<br>
_any_ load time to be functional. Since we're competing with Eclipse, we<br>
could make that a big advantage: A development-environment that is<br>
light-weight with nearly instant startup time.<br>
<br>
I would like KDevelop4 to be light-weight, like a much more powerful drop-in<br>
replacement for kate, where the user doesn't have to think whether he wants<br>
to take the overhead of firing it up.<br>
<div class="Ih2E3d"></div></blockquote><div>Maybe the problem here is opening projects on startup.<br><br>Even if we cached the project model, we would have to parse in case the any part of the project has been modified.<br>
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.)<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> I would add as well incremental parsing for c++ since you said it would be<br>
> straightforward and it is a pitty when you are writing and have to wait for<br>
> the editor to write it down.<br>
<br>
</div>I have that problem in focus. However incremental parsing would just be a<br>
workaround, and isn't directly related to the problem. First the real problem<br>
will be fixed(short GUI lockups due to thread locking stuff), then the<br>
parsing will be made more efficient, and then comes incremental parsing, in<br>
that priority order.<br>
<div><div></div><div class="Wj3C7c"><br>
Greetings, David<br>
<br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br></div>