Rough KDevelop 4.6 Planning

[Ivan Shapovalov]

On 18 December 2012 20:45:10 Milian Wolff wrote:
> Hey there, while we are talking about 4.5, I'd like to get some input on
> what you think we should do for 4.6 eventually.
> 
> Personally, for 4.6, I hope to land the two big refactorings I'm working on
> currently:
> 
> On one hand the Path stuff in the sharedurls branch which promises a much
> more straight forward *and* efficient (local/remote) Path handling in
> KDevelop.
> 
> Secondly, I started another interesting refactoring on the weekend related
> to our ItemRepositories. Looking some more at IndexedString, I managed to
> cleanup its API (removing potential encoding pitfalls) while also speeding
> it up quite considerably (about factor of 2 for string serialization, and
> about 20% for string deserialization). I will concentrate on landing the
> IndexedString refactoring first, then also hope to repeat the optimizations
> there for the other item repositories, and - while at it - cleaning up the
> mess of code that is itemrepository.{h,cpp}. I'm confident that by writing
> tests and using our existing tests, I can keep this working without any big
> breakages.
> 
> These two should result in a very noticeable performance gain, both memory
> and speed wise.
> 
> After that is done, I hope to have some time to investigate the "KDevelop
> commandline" idea we had at the Vienna sprint - lets see.
> 
> What do you guys have in mind?
> 
> Cheers

Hi!

For now I'm planning, like Kevin, to focus on general quality and, in 
particular, on code quality (i. e. refactorings). So far I'm going to:

1) Implement some kind of better history+multiple output view (as discussed 
here some time ago) - but still thinking on how to do it optimally;

2) Integrate build view and problem reporter;

3) Complete my WIP on job classes (which began with OutputExecuteJob and 
cleaning up builder jobs) - that is, factor out common base of VCS job classes 
and clean them up;

4) Do something with Git plugin which has already been noted here as a big 
structural mess;

5) Introduce "generic build configurations" (now there are build directories in 
CMake and build configurations in kdev-custombuildsystem) - and make the 
corresponding controls in the UI like launch configurations currently have;

6) This probably won't be done for 4.6: write a supplemental "KDevelop 4" 
generator for CMake (pushing it upstream there) and write an alternative 
project manager plugin which will read generated file with per-target and per-
directory properties instead of parsing CMakeLists files, achieving the 
exhaustive compatibility at almost no cost. ;)

Notes: The idea behind (5) is fast "Debug"<->"Release" switching, and the one 
behind (6) is that I can't make existing CMake plugin to resolve
"#include <QFile>" and I doesn't feel that fixing a hand-built fundamentally 
incomplete parser is a right thing to do when there is an existing reference 
implementation. (Also, our CMake support doesn't handle cross-compilation 
well.)

Cheers!

- Ivan Shapovalov