Rough KDevelop 4.6 Planning

[Morten Volden]

2012/12/18 Milian Wolff <mail at milianw.de>

> 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(
http://git.reviewboard.kde.org/r/104574/ ) 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
(http://www.jcell.co.za/splash.htm) 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
corner).

Cheers

Morten

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


-- 
- When the split is pulled, mr. Grenade is no longer our friend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20121220/14b2b371/attachment.html>