kdevelop (Re: Proposal to plan for "Milestone Releases" on the way to KDE4)
Sébastien Laoût
slaout at linux62.org
Fri Jan 27 23:00:52 GMT 2006
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.
More information about the kde-core-devel
mailing list