Problems installing and running Gideon

Marcus Gruendler runner at
Sun Jun 17 10:57:38 UTC 2001

On Wednesday 13 June 2001 22:19, you wrote:
> On Sun, 10 Jun 2001, Marcus Gruendler wrote:
> > * I find the project tab with two views (subprojects on top, categories
> > or programs on bottom) a little confusing, since I don't understand their
> > purpose. (This could of course be caused by my own incompetence ;)
> The purpose of separating them is that you get lost in the tree very
> quickly when you put both together. In my initial implementation, I
> did it this way, and found myself scrolling up and down all the time in
> order to find the target I was searching. Also, the tree can become
> quite wide. When targets are separated from subdirectories, the width
> of the subdirectories tree doesn't matter so much because most of the
> time you work in one directory and not across several. At least this
> is my personal experience.
> >   I think the project management should be centralized in one dialog
> > where all customization are performed. Currently you have to right click
> > on a subproject in order to adjust compiler settings and right click on a
> > program in order to adjust linker flags.
> Making a separate dialog would certainly solve some of the problems I
> described above, because then a larger part of the tree could be dis-
> played. I think deciding between a separate dialog and the always
> visible embedded view is a matter of taste, so I'm undecided about it.
> The compiler settings are on a per-subproject basis because automake
> implements is that way. AFAICT, the next automake version will support
> per-target options, so we should also support this later when it
> becomes standard.

Okay, I understand your concerns about getting lost in a large tree. If you 
are undecided whether to use the tab or a dialog then use both. The tab 
provides quick access to certain targets and the dialog provides the whole 
information in its context.

The advantage of the dialog is that you can show the complete project and 
select the elements you are interested in. The dialog can show the project 
tree on the left side where you can select subprojects, targets, directories 
or files and on the right side you will see the corresponding settings. This 
would save you a lot of right clicks in the tab.

BTW, is there an inheritance of settings from the parent project? That might 
be usefull. 

And finally I want to suggest a notion of "workspace" and "projects" instead 
of "projects" and "subprojects". Well, but this is very much a matter of 
taste and shouldn't be on top of your priorities ;-)

> > * The order of the tabs should be changed, so that the "Books" tab is
> > further on the right and "Project" and "Classes" are visible at first.
> Hmm, that's not trivial because the order is more or less 'random'...

Isn't there an "insertFirst()" method in the tab widget? (I don't know the 
API yet) Then we could at least put the project tab in front.

> > (There seems
> >   to be a bug in my version which inserts two "Watch" tabs instead of
> > one.)
> Maybe one from the java debugger?

Hmm. That's possible. But then I think the java related menues/tabs should be 
disabled/removed when editing a C++ project and vice versa.

> > * The "Watch" view should not be the same as in KDevelop-1.4 since it is
> > very difficult to watch variable values when variable names are long.
> > Then the width of the name column is resized to the full length of the
> > name and you have to scroll to the variable value on every change. If the
> > variable value is put on the next line ( or as a child of the name entry
> > ) this does not happen.
> Would it be an alternative to truncate the first column and avoid
> horizontal scrolling?

Okay that would make it more usable though not perfect, because you have to 
resize it again if you want to see the complete name. Sorry, I don't have a 
good solution to this problem right now. Maybe we could show the value in a 
child of the name but that may consume too much vertical space. 

Sorry for the late reply, but I'm quite busy right now.

Bye, Marcus

Marcus Gruendler
eMail: runner at
WWW  :

to unsubscribe from this list send an email to kdevelop-request at with the following body:
unsubscribe »your-email-address«

More information about the KDevelop mailing list