Want to participate in KDevelop4 development

[Andreas Pakulat]

On 24.09.07 11:55:55, Mohammad Bhuyan wrote:

First: Thanks for writing up this list.

> (1) Project Manager
> 
> 
> - File View: Tree view of the files belonging to the project

Wanted to raise discussion on that later, but since we're on it: IMHO
our "Project View" should optionally show _all_ files in the project,
not just those that can be built. Rather we should have a filter to
leave out non-project files.

> - Namespace / Class View: Treeview of NameSpace -> class -> Members

This should be more "general", so that it can display the hierarchy of
any file using a object-oriented or functional programming language.

> - Can we jump to the source code?

Not yet, but of course thats planned.

> - Given the various type and complexity of the build method and
> process, a separate UI view to deal with
>   project build management.

Well, I already explained that before, but IMHO we should provide only a
very limited UI for the buildsystems we support. Simply because all of
them are too complex to create a UI that covers all features. So we need
something thats easy enough for simple projects. For complex projects we
should aim for a texteditor for the buildsystem files and good
"code-features" for that (i.e. completion, navigation and so on).

> IDEs like VisualStudio has a nice approach of having a "Solution" to
> contain/manage multiple projects. I find it very intuitive for
> developers to go with the
> 
> concept of a "Solution" contains "Projects" and all of the are managed
> through "Solution Explorer". What is the vision of Kdevelop4 regarding
> this?

So far we're aiming for a loosely coupled list of projects, not stored
into a separate file. IMHO the list of opened projects should just be a
list of url's of the .kdev4 files. If a project then depends on another
project that should be expressed by a configuration item in that
projects .kdev4 file, naming the projectname of the other project (not
the .kdev4 file). This is not implemented yet.

> (1.*) Property View: Properties of elements (Project, File, Class, etc)
> 
> - It is closely associated with the context/selection of Project Manager.

I don't see a use-case for them, especially not for file and class. For
Project users should use the KCM. I'm not sure how this is done in
eclipse (i.e. how the Properties are declared on a project), but I've
never used it at all, except for changing a svn property where eclipse
forces you to use it.

> (3) Output
> 
> - Output from build process.

Done (for make output), including highlighting of errors/warnings and
"clickability" for those.

> - Separate presentation of Warning, Error etc in grid/table

That needs happening still, but in KDev3 this was directly provided by
the language support and its parser instead of parsing the buildtools
output. 

> - Click code to jump to help file / Internet location

Huh? How do you mean that, can you elaborate a bit please?

> - sort/grouping of error/warning by type, module etc

Yeap, should be quite easy with Qt4 model/view

> - Project console (Note: not shell console) where events and messages
> about project/s are logged while things happen through UI.
>   like "Hello.c added.", "Dir added to project X", etc. This i think
> can serve as visual log, history Trace, and trouble shooting tool.
>   Also will be of excellent use during the development of the IDE itself.

Hmm, that sounds cool for some basic debugging of KDevelop4's UI itself,
but I don't see our users need that. I mean if they add a file via UI
and it doesn't show up, a message appearing or not appearing doesn't
help that much...  And for important things like "Couldn't create dir,
do you have enough permissions" there are message
boxes/KNotify/kWarning/kFatal.

> (4) Console/Shell Access
> 
> - Konsole already integrated.

Not quite, there are some things missing, for example being able to
easily switch console to the builddir and sourcedir of the currently
opened file. And some of the devs dream about things like typing "build"
and with that executing the build inside kdevelop.

> (5) Debugging:
> 
> 
> (*) irrespective of the debugger backend, the UI will integrate the following
> 
> - Debug Output console: Assert / Debug / Trace messages during execution

I doubt this can work. We only have stdout/stderr and usually it doesn't
make sense to separate "normal" output from debug and error messages
because you'll loose the information where this happened.

> (6) DUChain
> 
> (Note) The name is a bit cryptic. Can it be better? The concept is
> really cool. New to me and I am yet to understand.

Is DefinitionUseChain better? After all thats exactly what it is.

Andreas

-- 
You will step on the night soil of many countries.