Project Management View ideas

Hi,

so the remove-the-splitview idea was torn down with pretty
good
arguments 

Thus I'd like to present a more complete vision of how the
project
management view could be in KDevelop4. 

- Showing buildsystem and non-buildsystem files, that is the
project
  model will get new item types for this. I'm not sure yet
how to
  populate those

- Allowing to "remove" individual files/folders
from project view (i.e.
  marking as ignore)?

- colorization/extra information from vcs interfaces (long
term)

- Filtering out non-buildsystem and obviously also
non-project files
  (distinction as explained above)

About the split-view:

- optionally show a detail view, if certain types of items
are selected
  in the overview
  * if folder is selected show targetlist from
folder+subfolders
  * if target is selected show filelist

The splitview could then get some special actions in it,
like
adding/removing files to/from a target if a target is
selected. Or
building/installing all targets that are shown if a folder
is selected
(and thus all targets in it are shown). But I don't want to
add anything
that will be duplicated on the toolbar.

About main menubar/toolbar: I was thinking we could do
something similar
as Eclipse has for running apps. That is we have a menu item
"Build..."
that opens a dialog with checkable project/targets tree
hierarchy (no
deep nesting, just plain list) to select what to build. Then
we'd have
both a menu item and a toolbar item "Recent
Builds" which contain
something like the last 5 builds to re-run them. Same thing
for install
and clean. And these are perfect candidates for the keyboard
shortcuts,
so you can easily re-run the last build of your
project/target
combination.

Of course the management view will also have context menu
items for
things like build, install, add/remove files and so on (in
the long
term), but as has been pointed out by Hamish and David thats
not the
easiest way to access these things.

Andreas

-- 
You're being followed.  Cut out the hanky-panky for a few
days.

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

On Thursday 08 November 2007 01:06:27 Andreas Pakulat
wrote:
> Hi,
>
> so the remove-the-splitview idea was torn down with
pretty good
> arguments 
>
> Thus I'd like to present a more complete vision of how
the project
> management view could be in KDevelop4.
>
> - Showing buildsystem and non-buildsystem files, that
is the project
>   model will get new item types for this. I'm not sure
yet how to
>   populate those
>
> - Allowing to "remove" individual
files/folders from project view (i.e.
>   marking as ignore)?
>
> - colorization/extra information from vcs interfaces
(long term)

I think it would be great if we could get some additional
colorization/icons 
from the duchain(show the parsing-progress), and maybe from
teamwork.

> About the split-view:
>
> - optionally show a detail view, if certain types of
items are selected
>   in the overview
>   * if folder is selected show targetlist from
folder+subfolders
>   * if target is selected show filelist
>
> The splitview could then get some special actions in
it, like
> adding/removing files to/from a target if a target is
selected. Or
> building/installing all targets that are shown if a
folder is selected
> (and thus all targets in it are shown). But I don't
want to add anything
> that will be duplicated on the toolbar.

That sounds good. We can decide later what exact actions we
want there.

> About main menubar/toolbar: I was thinking we could do
something similar
> as Eclipse has for running apps. That is we have a menu
item "Build..."
> that opens a dialog with checkable project/targets tree
hierarchy (no
> deep nesting, just plain list) to select what to build.
Then we'd have
> both a menu item and a toolbar item "Recent
Builds" which contain
> something like the last 5 builds to re-run them. Same
thing for install
> and clean. And these are perfect candidates for the
keyboard shortcuts,
> so you can easily re-run the last build of your
project/target
> combination.

I haven't used eclipse seriously. This does sound a little
complicated, and 
for example if you have opened the projects
"kdebase" and "kdelibs" how 
should the hundreds of targets be represented in that list?

What about this:
We could introduce something like a build-list. In the
project-view, you could 
have a context-menu action and a split-view button "Add
to build-list".
The "Build" menu would show you that build-list,
so the "Build" entry would be 
called "Build kdesupport, kdelibs, kdevplatform,
kdevelop", and there would 
be an entry "Clear build list".
Additionally the project-view and split-view could contain a

button "Quickbuild", that simply builds the
selected target without using a 
build-list.

Previous build-lists/quickbuilds could be accessible through
the "Recent 
Builds" as you proposed.

The advantage would be:
- Scalable(no big list of targets)
- Natural way of specifying the build-order

Should we ever implement that feature, we could even
represent the build-lists 
by working-sets, and thereby store them to disk. 

greetings, David

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

On 09.11.07 11:24:58, David Nolden wrote:
> On Thursday 08 November 2007 01:06:27 Andreas Pakulat
wrote:
> > About main menubar/toolbar: I was thinking we
could do something similar
> > as Eclipse has for running apps. That is we have a
menu item "Build..."
> > that opens a dialog with checkable project/targets
tree hierarchy (no
> > deep nesting, just plain list) to select what to
build. Then we'd have
> > both a menu item and a toolbar item "Recent
Builds" which contain
> > something like the last 5 builds to re-run them.
Same thing for install
> > and clean. And these are perfect candidates for
the keyboard shortcuts,
> > so you can easily re-run the last build of your
project/target
> > combination.
> 
> I haven't used eclipse seriously. This does sound a
little complicated, and 
> for example if you have opened the projects
"kdebase" and "kdelibs" how 
> should the hundreds of targets be represented in that
list?

 I
already implemented the basic thing with just projects. But
this
morning it occured to me that the extra dialog isn't needed
at all. We
can easily have checkboxes for Build/install inside the
project
management view. That way you can easily select which stuff
to build,
including subfolders or targets specifically (helpful when
working in
kdelibs when you don't want to build/relink the tests) and
have only 1
action (including shortcut) to build anything thats selected
in the
management view.

> What about this:
> We could introduce something like a build-list. In the
project-view, you could 
> have a context-menu action and a split-view button
"Add to build-list".
> The "Build" menu would show you that
build-list, so the "Build" entry would be 
> called "Build kdesupport, kdelibs, kdevplatform,
kdevelop", and there would 
> be an entry "Clear build list".

Doesn't scale well, especially when allowing to select
individual
folders/targets. The checkboxes allow to easily see where
builds are
happening, with the tristate-thing (i.e. grey checkbox if
not all
subitems are going to be built)

> Additionally the project-view and split-view could
contain a 
> button "Quickbuild", that simply builds the
selected target without using a 
> build-list.
> 
> Previous build-lists/quickbuilds could be accessible
through the "Recent 
> Builds" as you proposed.
> 
> The advantage would be:
> - Scalable(no big list of targets)
> - Natural way of specifying the build-order
> 
> Should we ever implement that feature, we could even
represent the build-lists 
> by working-sets, and thereby store them to disk. 

Hmm, given the above I think a way to store the list of
selected project
items away is quite cool. Makes it easy to switch between
different sets
of projects...

So my plan for today is getting the checkboxes into the tree
and making
them react to a build action (not really that easy as we
might have
multiple project management views, which need to be synced).
Then the
next step is to create build-sets from that and provide a
view onto
that, shouldn't be much work.

Andreas

-- 
You are only young once, but you can stay immature
indefinitely.

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

On Friday 09 November 2007 12:10:19 Andreas Pakulat wrote:
> > What about this:
> > We could introduce something like a build-list. In
the project-view, you
> > could have a context-menu action and a split-view
button "Add to
> > build-list". The "Build" menu would
show you that build-list, so the
> > "Build" entry would be called
"Build kdesupport, kdelibs, kdevplatform,
> > kdevelop", and there would be an entry
"Clear build list".
>
> Doesn't scale well, especially when allowing to select
individual
> folders/targets. The checkboxes allow to easily see
where builds are
> happening, with the tristate-thing (i.e. grey checkbox
if not all
> subitems are going to be built)

Checkboxes might be ok too, but personally I would prefer if
I could see 
easily what exact actions I'm triggering with a build,
without needing to 
search the tree.

Another question: How to exactly determine the build-order
of checked items?

Currently I usually do something like this when building:
Make -C ../../kdevplatform && sudo make -C
../../kdevplatform install && 
make -C .. && sudo make -C .. install

Which could be nicely represented by some kind of
action-list, that could 
contain "build kdevplatform, install kdevplatform,
build 
kdevelop/languages/cpp, install
kdevelop/languages/cpp". If one item in the 
action-list would fail, the following would not be executed,
similar to the 
kdesvn-build script.

I think it would be great if we could provide something like
this.
An additional great feature would be allowing to add custom
commands to the 
build-list, to fit all the custom build needs out there.


Such a build-list could be synced with the checkboxes in the
project tree.

So here a proposal inspired by the above thoughts:
- Have an additional small build-list widget, maybe in the
same dock with the 
project-manager, that can contain a list of actions.
- Synchronize project-view and build-list
-   When you check an item in the project-view for build,
add it to the list.
-   When you uncheck an item in the project-view, remove it
from the list.
-   When removing an item from the build-list, uncheck it in
the project-view.
- Allow dragging around items in the list to change the
build-order.
- Allow inserting custom command-actions into the list, the
output can be 
shown in the application-output view.
- When a build is triggered, execute all the actions in the
build-list in 
order, and show the progress by adding green checkmarks to
successfully 
processed items.
- When an item fails, add a red cross to it, and stop
building.
- When clicking an item in the list, show the output.

Since we anyway need a way of tracking the progress while
building multiple 
targets, this might be a nice way.

greetings, David

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

On 13.11.07 18:41:49, David Nolden wrote:
> On Friday 09 November 2007 12:10:19 Andreas Pakulat
wrote:
> > > What about this:
> > > We could introduce something like a
build-list. In the project-view, you
> > > could have a context-menu action and a
split-view button "Add to
> > > build-list". The "Build" menu
would show you that build-list, so the
> > > "Build" entry would be called
"Build kdesupport, kdelibs, kdevplatform,
> > > kdevelop", and there would be an entry
"Clear build list".
> >
> > Doesn't scale well, especially when allowing to
select individual
> > folders/targets. The checkboxes allow to easily
see where builds are
> > happening, with the tristate-thing (i.e. grey
checkbox if not all
> > subitems are going to be built)
> 
> Checkboxes might be ok too

Just dropped that idea 

> but personally I would prefer if I could see 
> easily what exact actions I'm triggering with a build,
without needing to 
> search the tree.

Ok, there's one thing I'm not sure about yet: 

1 Buildset or multiple Buildsets? I mean does it make sense
to keep a
list of targets/folders/files around that you currently
don't build, but
switch often enough that manually readding the items is too
much a pain? 

If we decide for multiple buildsets, I'd like to have
something similar
to the current fileview, i.e. first it shows the buildsets,
then you
"open" one and it shows the contents. With easy
navigation back and no
tree hierarchy.

> So here a proposal inspired by the above thoughts:
> - Have an additional small build-list widget, maybe in
the same dock with the 
> project-manager, that can contain a list of actions.

It currently has a list of items to build. In fact thats all
thats
really needed - IMHO. Currently adding/removing is manual,
but I'm
planning to add drag'n'drop support sooner or later. Also it
currently
isnt' stored, but that'll get fixed as soon as I find out
whats wrong
with my getFolder() method.

However that leads to another question: 
Where to store the buildset? I think it should be stored in
kdevelops
configuration as its cross-project and thus as soon as you
close the
project where its stored it'll disappear.

> - Allow dragging around items in the list to change the
build-order.

I'll first add up/down arrows, but yes that'll come with the
other dnd
support. Though I'm not yet sure how to do this with
inter-project deps,
which I'd like to add to KDevelop4. 

> - Allow inserting custom command-actions into the list,
the output can be 
> shown in the application-output view.

No this is not needed at all, or rather: We already can have
that
without having any special custom commands. All thats needed
is a
GenericBuildSystemManager which allows to define the
commands run for
build(), install() and Co. Then the items created by this
custom manager
can be used the same as other items in the buildlist.

> - When a build is triggered, execute all the actions in
the build-list in 
> order, and show the progress by adding green checkmarks
to successfully 
> processed items.

That latter is a nice idea, shouldn't be too hard to add.

> - When clicking an item in the list, show the output.

That might be problematic, as the projectmanagementview
doesn't know
anything about where the output for a build goes to. The
only way I see
that this could work would be by exposing the whole Buildset
stuff via
an interface/API.

Andreas

-- 
You have had a long-term stimulation relative to business.

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

On Friday 23 November 2007 02:51:13 Andreas Pakulat wrote:
> Ok, there's one thing I'm not sure about yet:
>
> 1 Buildset or multiple Buildsets? I mean does it make
sense to keep a
> list of targets/folders/files around that you currently
don't build, but
> switch often enough that manually readding the items is
too much a pain?
>
> If we decide for multiple buildsets, I'd like to have
something similar
> to the current fileview, i.e. first it shows the
buildsets, then you
> "open" one and it shows the contents. With
easy navigation back and no
> tree hierarchy.
The question is if we need so many build-sets that this
would be needed.
Personally I'd probably have 3 build-sets around while
hacking kdevelop:
1. Build kdesupport, kdelibs, kdevplatform, kdevelop
2. Build kdevplatform, kdevelop
3. Build kdevplatform/language/duchain,
kdevelop/language/cpp
So maybe a simple tab-interface might be more accessible.

> > So here a proposal inspired by the above
thoughts:
> > - Have an additional small build-list widget,
maybe in the same dock with
> > the project-manager, that can contain a list of
actions.
>
> It currently has a list of items to build. In fact
thats all thats
> really needed - IMHO. Currently adding/removing is
manual, but I'm
> planning to add drag'n'drop support sooner or later.
Also it currently
> isnt' stored, but that'll get fixed as soon as I find
out whats wrong
> with my getFolder() method.
>
> However that leads to another question:
> Where to store the buildset? I think it should be
stored in kdevelops
> configuration as its cross-project and thus as soon as
you close the
> project where its stored it'll disappear.
Hmm maybe we need a global repository of build-sets, where
all the build-sets 
are stored, and each one is assigned to a set of projects.
As soon as all the 
projects are open, the set should be shown.
However I'd like the build-sets also be usable without a
project at all, so 
there should also be build-sets for "no project
open". 

> > - Allow inserting custom command-actions into the
list, the output can be
> > shown in the application-output view.
>
> No this is not needed at all, or rather: We already can
have that
> without having any special custom commands. All thats
needed is a
> GenericBuildSystemManager which allows to define the
commands run for
> build(), install() and Co. Then the items created by
this custom manager
> can be used the same as other items in the buildlist.
But I'd like it to be flexible enough to also work without a
project at all. 
Example: For my university exercises I usually have a one
very simpe 
source-file, and compile it using "g++ exercise.cpp -o
exercise", so it would 
be very comfortable being able to add such an action,
without much hassle, 
project-creation, etc.

Also think for example about commands like "svn
update". People like 
flexibility ;). Would it be a big effort allowing this?

greetings, David

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

On 23.11.07 09:59:12, David Nolden wrote:
> On Friday 23 November 2007 02:51:13 Andreas Pakulat
wrote:
> > Ok, there's one thing I'm not sure about yet:
> >
> > 1 Buildset or multiple Buildsets? I mean does it
make sense to keep a
> > list of targets/folders/files around that you
currently don't build, but
> > switch often enough that manually readding the
items is too much a pain?
> >
> > If we decide for multiple buildsets, I'd like to
have something similar
> > to the current fileview, i.e. first it shows the
buildsets, then you
> > "open" one and it shows the contents.
With easy navigation back and no
> > tree hierarchy.
> The question is if we need so many build-sets that this
would be needed.
> Personally I'd probably have 3 build-sets around while
hacking kdevelop:
> 1. Build kdesupport, kdelibs, kdevplatform, kdevelop
> 2. Build kdevplatform, kdevelop
> 3. Build kdevplatform/language/duchain,
kdevelop/language/cpp
> So maybe a simple tab-interface might be more
accessible.

No way, there's not enough horizontal space there for a tab
widget,
unless you only put numbers on it 

> > > So here a proposal inspired by the above
thoughts:
> > > - Have an additional small build-list widget,
maybe in the same dock with
> > > the project-manager, that can contain a list
of actions.
> >
> > It currently has a list of items to build. In fact
thats all thats
> > really needed - IMHO. Currently adding/removing is
manual, but I'm
> > planning to add drag'n'drop support sooner or
later. Also it currently
> > isnt' stored, but that'll get fixed as soon as I
find out whats wrong
> > with my getFolder() method.
> >
> > However that leads to another question:
> > Where to store the buildset? I think it should be
stored in kdevelops
> > configuration as its cross-project and thus as
soon as you close the
> > project where its stored it'll disappear.
> Hmm maybe we need a global repository of build-sets,
where all the build-sets 
> are stored, and each one is assigned to a set of
projects. As soon as all the 
> projects are open, the set should be shown.

Well, thats easy as an entry in the buildset will always
have 3
reference informations: a name, a project name and a
relative project
url of the folder it is in.

> However I'd like the build-sets also be usable without
a project at all, so 
> there should also be build-sets for "no project
open". 
 
Won't happen. We only support building kdevelop4 projects.

> > > - Allow inserting custom command-actions into
the list, the output can be
> > > shown in the application-output view.
> >
> > No this is not needed at all, or rather: We
already can have that
> > without having any special custom commands. All
thats needed is a
> > GenericBuildSystemManager which allows to define
the commands run for
> > build(), install() and Co. Then the items created
by this custom manager
> > can be used the same as other items in the
buildlist.
> But I'd like it to be flexible enough to also work
without a project at all. 

see above.

> Also think for example about commands like "svn
update". People like 
> flexibility ;). Would it be a big effort allowing
this?

svn up is not part of a buildset.

Andreas

-- 
You will be aided greatly by a person whom you thought to be
unimportant.

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

On Friday 23 November 2007 10:56:33 Andreas Pakulat wrote:
> Won't happen. We only support building kdevelop4
projects.

And what's the argument for that? Why shouldn't it be
possible to build using 
a command like "g++ exercise.cpp -o exercise", or
"./myBuildScript" without 
setting up a project?

Of course this also can be accomplished by good console
integration, but 
triggering by shortcut will always be more comfortable than
using the 
console.

greetings, David

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

On 23.11.07 11:09:10, David Nolden wrote:
> On Friday 23 November 2007 10:56:33 Andreas Pakulat
wrote:
> > Won't happen. We only support building kdevelop4
projects.
> 
> And what's the argument for that? Why shouldn't it be
possible to build using 
> a command like "g++ exercise.cpp -o
exercise", or "./myBuildScript" without 
> setting up a project?

Because thats not a use-case for an IDE. If you want to work
one a
single file, you should use an editor+shell, I don't see a
single reason
to fire up a fully bloated IDE for something like that.

Apart from that there's no API for doing this and I don't
like the
projectmanagerview do execution of arbitrary commands.

Its simply not how KDevelop4 is designed.

Andreas

-- 
You recoil from the crude; you tend naturally toward the
exquisite.

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

On Friday 23 November 2007, Andreas Pakulat wrote:
...
> If you want to work one a single file, you should use
an editor+shell, I 
> don't see a single reason to fire up a fully bloated
IDE for something like
> that.

-in order to not scare students away by having them type
cryptic commands at 
a "DOS prompt"
-in order to have an integrated debugger
-in order to have integrated help
-to be able to produce the preprocessed file/the assembler
file without even 
more cryptic commands
-in order to be able to navigate on logic level (go to
function etc.)

Alex

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