First let me say that Kdevelop is awesome!  I switch between Visual
Studio
6.0 and Kdevelop 1.1b2 (and their respective OSes daily) and I much
prefer
the simplicity and logical layout of kdevelop.  I can find what I need
faster
and with much less hassle.  It is easier to stay focused on the work at
hand
with kdevelop - which is exactly why IDEs exist!  Fantastic work,
everyone,
and especially to those who are engineering the layout.

Now, on to suggestions for improvements...  (sorry if some of these have
already been talked about here - if so please ignore them)


Bugs

1) The autosave-changed-files feature is a pretty big problem.  If you
   happen to be typing during the autosave, the flipping edit screen
   causes your keystrokes to be spread across all the files that get
   saved. A less destructive problem but still annoying is that if
   you are holding down the mouse at the time of the autosave (moving
   a slider looking for a region of code or something) the pointer grab
   is broken and you have to go and pick it up again.


2) Color syntax highlighting within preprocessor statements has a
problem:

        #define FUNC(x, y)   x < y && y > x

   causes the angle brackets and all within to be seen as "Prep. Lib"
   (which is used to color quoted preprocessor strings: #include "x.h")


3) Some colors are hard coded making text for some windows unreadable
   when using desktop color schemes that use light foreground colors on
   a dark background.  Ex. initial "tip of the day" hard codes the
   background color.

   (*** see my note below on finding complementary colors ***)


4) Unterminated strings only color syntax highlight to the end of the
   line.  Then need to color the rest of the screen.


5) The stdout window can grow without bound.  What is cool is
   that kdevelop and linux continue to both run fine (the extra
   memory apparently ends up on the swap device), but after
   generating about a million lines of text, try to exit kdevelop!


----------------

Features

a) (Most probably more a KDE issue than kdevelop but..) I want to be
   able to select semi-condensed fixed width fonts for the editor
window.
   (what is KDE's aversion to semicondensed fonts!?) The specific font
   I want to use is:

   -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1

	Anyone have a hack for this?


b) I would like to be able to rename a source or header file and have
   the project automatically update.


c) After a make or build I wish the messages window would remain at
   the top so I can catch the first error that occurred not the last.
   Also it would be nice if it displayed the errors in red and
   warnings in orange (or some other standout colors).

   (*** see note below on finding complementary colors ***)


d) And most annoying of all: I don't always run kfm or the rest of the
   KDE desktop.  Sometimes I run vtwm for a lean and mean windowing
   environment.  When kdevelop starts on a vtwm system the screen goes
   crazy - all the windows in all my virtual screens get re-parented
   and all iconified windows become uniconified.  Ich.  Can kdevelop
   have a startup mode that doesn't wreak havoc on the desktop when
   kfm is not running?  Many other K<apps> don't do this (kfind, kwrite,
   killustrator, kvirc)



-----------------

Finding complementary colors
(also probably more a KDE issue than kdevelop)

   Many (if not all) GUI applications/toolkits need some way to
   chose a foreground or background color that is "substantially
   different" from the other color.  Microsoft has has this problem
   since day one of Windows 3(!) and they still have not solved it
   (have they even noticed it?).  It would be great if KDE (and its
   apps) could intelligently handle non-standard (i.e. light on dark)
   color schemes.  (Note: the "CDE" example KDE color scheme is one
   of these!)

 Idea:

   A function to determine a suitable background color when the
   foreground color is fixed, or vise versa, would be a very useful
   thing to have around.  When viewed from a hue/saturation/value
   perspective the problem might be quite simple!  Suppose we convert
   rgb to hsv, leave Hue and Saturation alone, set the Value value
   "180 degrees" out of phase, and convert back to rgb?  (if Value is
   an 8 bit number, flip the top bit)  This should result in a
   complement that has a similar color and shade as the foreground
   but would be opposite in darkness.

   When multiple foregrounds are present the problem is tougher
   but probably similar.  Chose a hue and saturation that
   matches the users color scheme.  Find a Value that is furthest
   from the Values of all the predefined colors.  If there is not
   enough difference then changing the hue or saturation also could
   be a fall back.  The point is: it has to be readable first, and
   pretty second.


duane