Project Management View ideas

[Andreas Pakulat]

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.