Project Management View ideas
zwabel at googlemail.com
Fri Nov 23 08:59:12 UTC 2007
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,
Also think for example about commands like "svn update". People like
flexibility ;). Would it be a big effort allowing this?
More information about the KDevelop-devel