Kdevelop4 gsoc

[Andreas Pakulat]

On 21.04.08 23:11:57, Manuel Breugelmans wrote:
> Thanks for the confidence! I will definitly not let you down. 

Thanks for starting the discussion. I'm moving this over to the
kdevelop-devel mailinglist, please try to discuss anything there as I
might not always have time to answer in a timely manner. And it will get
you in touch with the other devs :)

> Any good resources you can recommend to a novice KDE developper? Be it 
> articles, papers, possibly a book? Especially useful might be something 
> related to the concrete differerences between qt and qt in a KDE context. ( 
> I've obviously already found http://techbase.kde.org/Development )

Well techbase is a good start and of course the Qt docs. KDE API's are
often modelled similar to Qt API. Other than that its mostly a matter of
"diving into the code". One thing I'd like to recommend here is that you
build and try out kdevelop4, we just had a hacker sprint and from the
experience of last week it is now usable for hacking on its codebase.
Its a bit slow, but has far better and more reliable code-navigation
features than KDevelop3, which is really good to get into unknown code
bases. Just check out the Jump-To-Declaration/Definition and Quick-Open
methods 

> Since the first part is focussed mostly on QxRunner it seems best to work in 
> in a local scm for now, instead of directly on the kdevelop svn? I rather not 
> be responsable for breaking kdev4 builds :)

Well, the thing is that at some point we probably want to get the code
into KDE's svn and still preserve history. This isn't always easily
possible when using any XXX-svn bridges. Also its easier for me to track
the progress because we have a mailinglist that gets all svn-commits
mailed to.

As far as breaking anything goes: Don't worry, usually thats fixed
within hours be either you or somebody else and generally KDevelop4 is
pre-alpha so its expected not to build for a day or two every once in a
while. Apart from that I'm not sure how much of the existing code you
will touch, so at most you'll break just your own new code which can
then be easily disabled in the CMake files.

> How do you prefer being contacted and updated about progress and problems? 
> Personal mail, mailing-list, irc, blog?

Any longer questions or discussions should go to the kdevelop-devel
list, don't worry about spamming that list with your development, other
devs are interested in your progress too :) 

For quick questions I'm usually available on irc in #kdevelop on
freenode.org (nick: apaku, apaku|work), however due to a day-time-job I
might not always see you pinging me. If you don't get me on irc feel
free to write a private mail.

Last but not least: A blog post after larger milestones is a good thing
to communicate your progress to a larger audience.

> Anything concrete you expect from me at this stage?

For now I think trying to get into the codebase and see how kdevplatform
API is designed is good. Try to get some ideas how you could design the
unit-testing framework. 

Once you have some idea about the code and want to start coding, we
probably should think about some milestones starting with what you have
in your application. 

Andreas

-- 
Your depth of comprehension may tend to make you lax in worldly ways.