Rough KDevelop 4.6 Planning

[André Stein]

Hi,

I have a new feature in mind which I miss from other IDEs. That is an output view which shows warnings or errors from the build process. An example is the "build issues" pane in Qtcreator:

http://docs.huihoo.com/qt/qtcreator/1.3/images/qtcreator-build-issues.png

The rationale behind this is to have the filtered problems in a consolidated list where every item per file and code location is listed only once. This is especially useful when compiling many jobs in parallel where a lot of normal output hides the real warnings and errors - which are often duplicates because same headers are included across different translation units.

My current idea would be to integrate the list in the build output plugin which already does the whole build process filtering. Some buttons could allow (additive) filtering of errors, warnings and hints.

Another possibility would be to implement a separate plugin and thus view which gets the filtered items from the output view. This of course would require some heavy refactoring as the current plugin is highly integrated and doesn't provide an Api to access build filtered messages.

What do you think?

Cheers,
André


Milian Wolff <mail at milianw.de> schrieb:

>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
>-- 
>Milian Wolff
>mail at milianw.de
>http://milianw.de
>_______________________________________________
>KDevelop-devel mailing list
>KDevelop-devel at kde.org
>https://mail.kde.org/mailman/listinfo/kdevelop-devel