Hi,

Here is my top-five wishes for KDevelop 4:

1. Autocompletion for included Qt&KDE headers

   With Visul Studio it's so snappy to LEARN C# by just typing a class name
   (or a variable and then a point) and see if what is proposed match what
   you want to do.
   I haven't used C# a lot (only at school) but with Qt there is a good
   documentation, so this is less needed (well, there is MSDN for C#, but they
   prefer big quantity to quality so we pass time to browse the site two times
   before going to the page we wanted). On Qt, I always use QtAssistant and
   never need to search the Web.
   But when I have memory-holes, Ctrl+Space for QT&KDE could help!

   Oh... And I never understood what's the difference between Ctrl+J and
   Ctrl+Space. I'm now used to press them twice in sequence to find the word
   I want in one or the other. Perapse the two functions could be merged!

2. Complete GUI for Scons/bksys XML format

   Autotools are a mess. KDevelop only have a thin interface to it.
   We are obliged to learn autotools one day or another to make interesting
   things.
   Scons is not better (learning Python just to compile a code!) but better
   structured. So it could be better managed automatically by KDevelop.
   Like checking a checkbox "Use KDEMM" and it will automatically import the
   KDEMM Scons package, add tests at ./configure time, tell me what
   #define is set when KDEMM is found on the target system, add linker
   options...

   I once heard that there will be an extension to Scons/bksys that will
   allow to configure projects with a simple XML file and that the Scons
   script read it and create/run the needed Scons code.
   It could be easily parsable by KDevelop.
   In any way, I never want to learn Scons: ideally KDevelop should wrap it.

   Currently, automake manager show groups of files like "Icons in kde_icons"
   or "Data in shell_rc".
   It's very cryptic. How somebody is expected to understand what it does
   without reading lot of tutorials?
   There is no option dialog for those groups that allow to map a "target" to
   a destination folder when installed.

   There is no way to add another target/group!
   Let imagine I want application-wide data like document templates and
   clipart galery.
   I would like to add two groups:
   - "templates/*" should be installed in "Application Data/templates"
   - "cliparts/*" should be installed in "Application Data/cliparts"
   - "icons/myapp.png" should be installed in "KDE Icons"
   - "tags/*" should be installed in "Application Icons"
   - "emoticons/mytheme/*" should be installed in "KDE Emoticons/mytheme"
   - etc... with every resources in KStandardDirs, and allow custom ressources
   I could imagine a dialog with a dropdown showing "Application Data Folder",
   "KDE Crystal Icon Theme", etc... a lineedit with an optional subdirectory
   and the folder (or files) to install in this ressource.

   Currently, those things are doable but we should create the Makefile
   ourself, and then, when KDevelop restart it see them and display them.
   No way to add or edit graphically the groups in KDevelop.

3. Code Refactoring

   I'm not the first to ask :-)

4. Make package for some standard distributions

   It's bad to wait for (and FIND) packagers for every major distributions.
   Perhapse there exists a system that can create different packages, like
   it is possible to "cross-compile" (compile a PPC binary on an x86 PC).
   Or KDevelop could provide such tool, dedicate a server that the packaging
   wizard will contact to know what and where libraries are installed on every
   distributions, etc...

5. "Really" Changing the version number graphically

   There is an option to change the version number of the project, but in all
   the KDE 3 lifespan it never worked seamlessly.
   I haven't tested KDE 3.5 but I'm now avoiding to change the version number
   too much, and when I really must, I use Konqueror Find/Replace in files to
   change the version manually (after exiting KDevelop), by at the same time
   trying to not change the version number of a build component that was using
   the same version number, and then rebuilding from "make distclean;
   rm ./configure; make -f Makefile.cvs; ./configure; make" (yes, the
   autotool template of KDevelop is quite buggy too and I had to learn
   autotool to make it myself).
   Quite heavy just for a number, but I hope KDevelop will interface better
   Scons than it does for automake.

Best regards,
Sébastien Laoût.