[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop
Subject:    Some ideas and a cvs frontend
From:       Bernd Gehrmann <bernd () physik ! hu-berlin ! de>
Date:       1999-03-16 16:45:42
[Download RAW message or body]

Hi folks,

I'm sure you have heard this hundreds of times, but I still
want to say that you have done a great work on kdevelop. It
integrates lots of features and has a fairly good editor.
What has impressed me the most is the high number of tooltips
and quickhelps that can be found throughout the IDE. This
should set a standard for other applications.

Having said that, I must say that I still prefer XEmacs. It is
_not _ a religion for me (I'm not a fan of webbrowsers written
in ELisp ;-) but simply a good editor that has many features
I enjoy. As I think there is still place for an IDE for Unix,
I have sat down a while and thought about "What would make
an IDE useful for me" or "What would convince me to switch to
another editor" and made a list. This may seem like a bold
wish, but nevertheless I got the impression that you are 
ambitious enough to think about at least some of these ideas 
(and implement them). (Note that I have tried kdevelop only quite
superficially, so I may be wrong in some points.)

1.) Make all functions available through configurable keybindings.
This includes all functions of the editor. Many people are used
to C-n to go to the next line, but this is reserved by "New file".
Making _both_ of them configurable is the way to go. For some 
functions like "Vertical Selections" I first have to go through
an options dialog, make my selection and then switch back in the 
options dialog. 

2.) Make it easy to switch between the last two used buffers 
(e. g. header and implementation file).

3.) Make multiple editor windows possible.

4.) The Windows menu should be sorted in last-recently-used order,
and each item should have an accelerator

5.) Automatical indentation.

6.) Paren matching

7.) hot key for "Goto next error"

8.) Incremental search. This is probably the most important feature
of XEmacs for me, and it's up to me why no other editor implements
this. It's soooo useful.

9.) Make the libc documentation available and implement something
like "Lookup the function name under the cursor in the documentation
index".

10.) If the cursor is above an #include statement, offer an option
"Goto this include file" in the rmb popup.

11.) In the file properties dialog, put a hint in the quickhelp 
which tells to which Makefile.am feature the respective ui element
belongs. It's nice to have a gui frontend for these things, but
when I'm used to writing Makefile.am's directly it's helpful to
see what belongs where.

12.) Not using geometry management for dialogs sucks. Making such
dialogs resizable by the user sucks even more (e. g. it's funny
to see that one can resize one of the printer setup dialogs in
such a way that the Ok button is _above_ the preview button ;-)
Fortunately, GM becomes much much easier with Qt 2.0 :-))

13.) Cygnus Source Navigator has a nice grep: You can not only type
in the pattern to search, but you can also choose from a combo box
a regexp into which your pattern is sprintf'd. For example, if I
choose "OBJECT->method(" from the combo box and type in "Foo" as
pattern, it searches for all calls of methods of object Foo
(in such a way that whitespace around '->' and before '(' 
doesn't matter).

14.) Just a side note: On Debian, the Qt documentation is in
/usr/doc/qt-doc/html


So far for the wishlist, let's come the "What _I_ can do"...
In the recent weeks, I have tried - using kedit as testbed -
to make a framework for document-oriented applications which
makes tasks like numbered/unnumbered backups, asynchonous
down- and uploads and RCS management easier. Now, over the last
weekend I implemented a dialog for looking through the revision
logs and finally found that my interest is shifting much more
in the direction of a full-featured log browser and cvs frontend
which is obviously overkill for normal applications.
If you are interested in what I already have, take a look at

ftp://linde.physik.hu-berlin.de/pub/bernd/screenshots/logtree.gif
ftp://linde.physik.hu-berlin.de/pub/bernd/screenshots/loglist.gif
ftp://linde.physik.hu-berlin.de/pub/bernd/screenshots/update.gif
ftp://linde.physik.hu-berlin.de/pub/bernd/screenshots/diff.gif
ftp://linde.physik.hu-berlin.de/pub/bernd/screenshots/blame.gif

Looking at kdevelop's todo list, nobody else seems to be working
on a cvs frontend, so here is my offer to write it. My current idea
would be to do it as follows:

*) Part I is a submenu, probably in the File menu, which offers
functions like "Commit", "Update", "Update directory". I'm not
sure whether these functions should be implemented directly in
the kdevelop binary. On the one hand, this would cause bloat,
on the other hand it might be good to couple the commit dialog
tightly with a changelog editor (I'm a fan of changelogs and
I find it a pity that people can hardly find the differences between
KDE 1.0 and 1.1 because of a lacking changelog).

*) Part II would probably be a standalone applications which allows
browsing through different revisions and differences between them,
merging branches to HEAD, checking out modules/branches.
I'm not sure about merging and resolving conflicts. It's probably
better to offer something like that in a full-featured editor
environment, but how extensible is kwrite in this regard?

Looking forward to your comments,
Bernd.

[prev in list] [next in list] [prev in thread] [next in thread]