Rough KDevelop 4.6 Planning

Morten Volden mvolden2 at
Thu Dec 20 21:13:25 UTC 2012

2012/12/18 Milian Wolff <mail at>

> 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.

I'd really love to see a memory viewer in 4.6. I'm willing to put in the
time and effort to make it happen (although I may need someone I can ask a
question or two with certain parts of the code.) That being said, I seem to
remember Ben Wagner did some work on this( ) but it seems that this never
made it to the repository - Anybody knows if Ben is still working on this?

Oh, and another thing that would be nice (Maybe even for 4.5.): A new
splash screen. Greeting the user with a brand new splash is IMHO a great
way to signal that things under the hood have changed. I think the splash
screens that Ruan Strydom made some time ago
( are pretty cool. I especially like
the center one in the top row
(although the branches should probably be moved somewhat to the lower right



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
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at

- When the split is pulled, mr. Grenade is no longer our friend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list