[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-bugs
Subject: kdevelop 1.1beta2 - bugs and features
From: Duane Voth <duanev () interactivesi ! com>
Date: 2000-02-28 16:47:18
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic