KDevelop4 UI

On 9/24/07, Andreas Pakulat <apakugmx.de> wrote:
> On 24.09.07 11:55:55, Mohammad Bhuyan wrote:
> > 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.
>

My thinking was, having the "solution" (anybody
want to coin a term
here?) concept hence a file to represent the solution will
have to
contain more than a list of .kdev4 file urls.

While I agree that inter project dependency metadata can be
contained
in the individual project files, but there are few
properties of
solution that things that should be provided at the
"solution" level.
Like,

The build configuration (Debug/Release) which either applies
to all
the project within the solution or through an option at
solution level
to let the individual project configuration to take
precedence.

Version control of the solution (with its projects) as an
entity.
Checkin/Checkout solution rather than individual project
basis. Of
course with the provision where projects within a solution
can reside
a different source repository than the solution file
itself.

This two being from top of my head along with the fact that
it has to
be future proof (yes yes, never happens but we try!) I would
think
that we need to carefully define the "solution
file" rather than
thinking of it as a flat list of kdev4 URLs.

And if the idea is accepted and matured , I would like to
start
implementation work on it.


> > (3) Output
> >
>
> > - Click code to jump to help file / Internet
location
>
> Huh? How do you mean that, can you elaborate a bit
please?
>

Clicking error/warning number (code) takes to corresponding
the help
file or internet location (TechBase??)


Will get back with more. Bit of a work pile to deal with at
this moment.


-- Soyuz

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

My thoughts on some of these issues:

> > 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.
> >

What would be the nature of these relationships?  Would
building a dependent project automagically build all its
depenedencies first?  Would the project file have absolute
paths to its dependent project files?  This would likely
prevent version control of the project files (a big weakness
in kdevelop 3).  The concept a "solution" file is
handy here.

>
> My thinking was, having the "solution"
(anybody want to coin a term
> here?) concept hence a file to represent the solution
will have to
> contain more than a list of .kdev4 file urls.
>
> While I agree that inter project dependency metadata
can be contained
> in the individual project files, but there are few
properties of
> solution that things that should be provided at the
"solution" level.
> Like,
>
> The build configuration (Debug/Release) which either
applies to all
> the project within the solution or through an option at
solution level
> to let the individual project configuration to take
precedence.

KDevelop does not have the concept of build configurations. 
This would be dependent on the build system being used, and
is a much more difficult concept to employ on *nix than in
windows.

> > > (3) Output
> > >
> >
> > > - Click code to jump to help file / Internet
location
> >
> > Huh? How do you mean that, can you elaborate a bit
please?
> >
>
> Clicking error/warning number (code) takes to
corresponding the help
> file or internet location (TechBase??)
>

Clicking on an error or warning takes you to the specified
file and line #.  The error/warning number itself would be
dependent on the compiler being used (gcc, intel, etc...)
and we have absolutely no knowledge of this.  Not to mention
we would have no control over any documentation that may or
may not exist.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 27.09.07 23:27:24, Mohammad Bhuyan wrote:
> On 9/24/07, Andreas Pakulat <apakugmx.de> wrote:
> > On 24.09.07 11:55:55, Mohammad Bhuyan wrote:
> > > 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.
> >
> 
> My thinking was, having the "solution"
(anybody want to coin a term
> here?) concept hence a file to represent the solution
will have to
> contain more than a list of .kdev4 file urls.
> 
> While I agree that inter project dependency metadata
can be contained
> in the individual project files, but there are few
properties of
> solution that things that should be provided at the
"solution" level.
> Like,
> 
> The build configuration (Debug/Release) which either
applies to all
> the project within the solution or through an option at
solution level
> to let the individual project configuration to take
precedence.

As Kris already said that doesn't really exist with our
buildsystems.
For CMake its possible to just have 2 builddirs with debug
or release
configuration and easily switch between those using the
cmake
configuration. This however doesn't work for autotools or
qmake
buildsystems, neither of those can clearly separate builddir
and
srcdir and none of the two have a really easy way to switch
between
builds.

> Version control of the solution (with its projects) as
an entity.

Its fairly easy to select a handful of projects and commit
them using
the project management view 

> Checkin/Checkout solution rather than individual
project basis. Of
> course with the provision where projects within a
solution can reside
> a different source repository than the solution file
itself.

Projects may even have different version control systems,
but with the
KDevelop4 VCS architecture that shouldn't be much of a
problem. We could
even have a dialog popping up if the user commits 1
file/project asking
wether he also wants to commit any changes in related
projects.

There's one thing with the solution though: What happens if
a project is
part of two solutions? Where do we group that project, do we
put it into
both solutions (storing-wise of course, but also visually)?
I'm not sure
if our view's can handle the same item popping up at
different places in
a tree (and a copy would make things much harder/memory
consuming).

> This two being from top of my head along with the fact
that it has to
> be future proof (yes yes, never happens but we try!) I
would think
> that we need to carefully define the "solution
file" rather than
> thinking of it as a flat list of kdev4 URLs.

Well, its not just a flat list of kdev4 urls, thats the
"last opened
projects" list. Maybe we could integrate the
solution-idea with David's
working-sets idea, but instead of files some working-sets
have projects
in it (and everything you do to the working-set, like doing
and svn
action) happens to 
 
> > > (3) Output
> > >
> >
> > > - Click code to jump to help file / Internet
location
> >
> > Huh? How do you mean that, can you elaborate a bit
please?
> >
> 
> Clicking error/warning number (code) takes to
corresponding the help
> file or internet location (TechBase??)

As Kris already said, thats close to impossible. I could
imagine
something like "search this in browser" action in
a context menu. That
would need selection of parts of the output lines though
(which AFAIK is
not really easy to do)

Andreas

-- 
Do not sleep in a eucalyptus tree tonight.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 27.09.07 10:29:16, Kris Wong wrote:
> My thoughts on some of these issues:
> 
> > > 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.
> > >
> 
> What would be the nature of these relationships?  Would
building a
> dependent project automagically build all its
depenedencies first?

That would be a possibility, either a kdevelop-wide option,
or a dialog
thats asking it (of course with a don't ask again option).
On that note:
I wonder wether kde4 already has a way of re-enabling these
questions, I
think not but IMHO it should...

> Would the project file have absolute paths to its
dependent project
> files?  This would likely prevent version control of
the project files
> (a big weakness in kdevelop 3).  The concept a
"solution" file is
> handy here.

No, each project would have a list of project _names_ as
dependecies.
Then the projectmanager can map these names to actual
projects that are
open. So you'd need to have the dependecies open in KDevelop
to have all
the inter-project-dep-stuff working, OTOH it should of
course be
possible to just checkout the kdevelop module, without the
need to also
checkout kdelibs just to build it ;)

> > My thinking was, having the "solution"
(anybody want to coin a term
> > here?) concept hence a file to represent the
solution will have to
> > contain more than a list of .kdev4 file urls.
> >
> > While I agree that inter project dependency
metadata can be contained
> > in the individual project files, but there are few
properties of
> > solution that things that should be provided at
the "solution" level.
> > Like,
> >
> > The build configuration (Debug/Release) which
either applies to all
> > the project within the solution or through an
option at solution level
> > to let the individual project configuration to
take precedence.
> 
> KDevelop does not have the concept of build
configurations.  This
> would be dependent on the build system being used, and
is a much more
> difficult concept to employ on *nix than in windows.

With CMake its relatively easy already, just switching a
combobox
selection in a config widget. But we shouldn't restrict
project deps to
the same buildsystem and for QMake it needs a considerable
amount of
setup to have fully separated builds. But a GUI switch would
mean the
QMake Manager has to write into "sophisticated"
qmake files which I want
to avoid at all costs ;) So I agree in the general case.

> > Clicking error/warning number (code) takes to
corresponding the help
> > file or internet location (TechBase??)
> >
> 
> Clicking on an error or warning takes you to the
specified file and
> line #.  The error/warning number itself would be
dependent on the
> compiler being used (gcc, intel, etc...) and we have
absolutely no
> knowledge of this.  Not to mention we would have no
control over any
> documentation that may or may not exist.

As said in my other mail: a way to easily let Google (insert
your
favourite search engine) find an error should be quite
helpful already.

It seems our new contributor comes from a MSVC/win32
background, where
things are _much_ easier, due to all its limitations.

Andreas

-- 
If you think last Tuesday was a drag, wait till you see what
happens tomorrow!

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel