<p>On Apr 20, 2012 6:44 PM, "Milian Wolff" <<a href="mailto:mail@milianw.de">mail@milianw.de</a>><br>
> > results). I'd like to demonstrate most of these live, then expect to<br>
> > be burnt alive at the end of the session by the Church of Emacs<br>
> > followers.<br>
><br>
> Heh, I like your humor :)</p>
<p>Humor? Where?</p>
<p>> Hmm things that need to be mentioned... always a big issue for me as well when<br>
> I did a talk on KDevelop. There is simply so much!<br>
><br>
> Imo you have a nice hook, i.e. kernel development - try to put in all the<br>
> little things that make you productive when using KDevelop. QuickOpen, context<br>
> browsing, semantic highlighting, ... The list should contain things you<br>
> personally use such that you can easily talk about them, imo.</p>
<p>Yes, these ones are core KDevelop features, but they scale particularly well in the case of the kernel so I will definitely cover them first.</p>
<p>> Other tools that come to my mind would be snippets that are quite nifty in<br>
> some situations (also known from lots of other editors). And of course the<br>
> Kate VI-Mode for all the VIM users in the crowd :)</p>
<p>Kate VI-mode is indeed a must. Without it I would not be using KDevelop myself. I think it would also be interesting to highlight the fact that KDevelop is independent of the editor - for instance, someone recently wrote a Qt port of Vim - if another person had the good idea to make a KPart out of it, you could have something quite interesting too.</p>

<p>> Then, if you have time, I would appreciate it if you could take the time to<br>
> quickly explain the attending developers that it's relatively easy to hack<br>
> KDevelop. It's mostly modular plugins after all... Tell them that we are open<br>
> to any contributions (even if I slack quite much and review requests always<br>
> need some time). You could also stress that we are *not* opposed to a<br>
> designated C language plugin (opposed to a C++ one with C99/C11 extensions) -<br>
> but that this would need someone to work on it.</p>
<p>Yes, attracting potential developers is one of the main points of this talk. I was myself surprised by how modular and accessible KDevelop is. There is a great potential for developers that is not exploited because most people mistakenly see KDevelop as a sort of an attempt to mimic Visual Studio. Also people need to be more aware of the fact that it is perfectly usable.</p>

<p>> PS: If you need any help in preparation or such, just hit us up!</p>
<p>I'd so appreciate if some of the core KDev developers would be kind enough to review and give feedback & suggestions on early versions of the slides (off list, of course). If some of you don't mind doing so, please let me know!</p>

<p>Also there are a couple of features I'd like to implement to set the KDevelop solution out of the ctags/cscope flock. One of them in particular is the ability to track the possible values of function pointers in the DUChain and to give a list of potential candidates in the function popup window (much like what is done for overridden virtual functions in C++). This is heavily used in the kernel, is very confusing for beginners, and would just be a killer feature to show. I will open a separate thread for this, any kind of help/guidance that would speed things up would be extremely welcome.</p>

<p>Thanks!<br>
Alex.<br>
</p>