Getting the current active project

Andreas Pakulat apaku at gmx.de
Sat Mar 31 14:58:44 UTC 2007


On 31.03.07 17:18:41, Andras Mantia wrote:
> On Saturday 31 March 2007, Andreas Pakulat wrote:
> > Hmm, currently we don't because KConfig doesn't support reading from
> > remote urls. I have currently no idea how we could make this work,
> > except by copying the project file to the remote location after
> > project closing.
> 
> That's the solution I also used in Quanta in some places. Store a copy 
> of the file in a temp directory and upload when needed.
> Not supporting remote projects is a showstopper for us. 

Ok, we need to talk about this again, especially how remote projects are
used (i.e. multiple developers using the same remote project), so I'll
start a separate thread later today for that.

> > > > > Thereby I request to introduce back the notion of the current
> > > > > project in the KDevelop platform.
> > > >
> > > > What happens if your user actions or the other stuff doesn't get
> > > > a project?
> > >
> > > It will limit the user, so he cannot run scripts that work on the
> > > active project, only on the active document (and probably the
> > > folder where the document lies).
> >
> > I meant what if currentProject() returns 0 instead of a valid
> > IProject*.
> 
> If it returns 0 I assume that there is no project loaded.

Which is wrong actually.

> This is not the problem, as even before we never relied of a project
> being loaded, Quanta (in contrast to KDevelop 3.x) was able to work on
> files without loading a project.

The platform can work without a project too, however assuming there's no
project because currentProject() returns 0 is not a good idea. If your
actions also can work on "current document", then why not use that to
first find a project and if there's no project for the "current
document", then work without project. (There's IIRC not the full API
ready for this, but I'm working on it ;)

> > > You mean what will happen if no project is opened? That's not a
> > > problem, as in that case the path given to the script will be the
> > > path of the active document. This workes (and worked) fine.
> >
> > Yeah, but what happens if the script uses your proposed %projectbase
> > and projectbase is suddenly empty? I guess I have to look into
> > Quanta's code to properly understand that.
> 
> I checked what happens: the "%projectbase" string is passed literally 
> (the script can detect this). In case of KPart plugins, in this case 
> the path to the current document is passed instead of the path of the 
> project.

Ok. I know its hard to know what users do with this, but do you know of
any instances of this feature that works on a project itself, i.e.
doesn't care about current document but only uses %projectbase? 

> > > > Then again there's no "current item" in the treeview and I
> > > > don't think its sane to just select the top-most project in the
> > > > treeview...
> > >
> > > Sorry, what treeview is this?
> >
> > Uhm, the projectmanagerview (do we have another treeview in kdev4?),
> 
> file manager? ;-) Oh, it's not a real tree though.

Exactly :)

> > its visible only after opening a project.
> 
> Sincerely I do not understand that treeview, I loaded a project, and it 
> lists some directories and that's all (it might be that my project file 
> is too old, and it doesn't work well).

In the case of the genericprojectmanager it just lists all files in the
project directory. We need to extend that somewhat so it works similar
to KDev3.4-svn's custom makefile manager (without the makefile part)

> But now I see that if you open another one, both will appear in the same 
> treeview. I didn't test this before. ;-)

:) Thats called multiple projects.

> What I think would be the same approach is to think about what the 
> current project means:
> 1) is the current project always manually selected and it doesn't change 
> if you select a document from another project?
> 2) does the current project change automatically when you switch to a 
> document belonging to another project?

> Both have pitfalls, from what I see:
> 1) makes sense when you think from "building" point of view. You select 
> a project, and when you start to build,run,debug the action will act on 
> this project. The problem is that you might be tempted to work on 
> another file - from another project, press build, and you build the 
> wrong project.

Hehe, the question is wether we will actually have a "Build" action. I'm
currently in favor of one or both of the following approaches:

a) Context Menu in the projectmanager view
b) Projects Menu, containing all projects. Each with a submenu having
options for that project, i.e. Build, Install, Configure, Close... I
just did something similar for the Configure case, see
Settings->Configure Project in up-to-date KDev4.

> 2) in this case what will happen if the current document is not part of 
> any other project.

Current project won't change in that case.

> I'm not sure which way to go is better. 2 might be more "cool", but 1 
> might make more sense and would be more clearer for the user.

I'm also in favor of one. BTW: I think run/debug should be tackled
completely outside any project, i.e. it should work like in Eclipse. You
can create a "Runnable" item, that can be run/debugged and can reference
a "target" in an autotools/cmake/qmake project, or just an executable
"somewhere".

> Actually what I think would be best to combine this project management 
> with the so called "project views" in Quanta (which IIRC is also 
> present in KDevelop 3.4). Or we can call it workspaces. Every opened 
> project will have a workspace, which could include (among others?) the 
> opened documents. Switching from one project to another would require 
> an explicit action from the user and would mean:
> - saving the workspace for the actual project
> - remove this workspace (close - or hide for performance reasons - the 
> documents)
> - load/show the new workspace of the new project
 
Thats called 1 project at a time and personally I don't want that. I
want to quickly jump between projects, for example in the last two weeks
I often had the need to change or just read kdelibs code and that would
be much easier if I would've had kdev4 and kdelibs4 code available at
the same time.

> This would be just like the case when you have two opened KDevelop 
> sessions and switch between them. This scenario doesn't stop you to mix 
> documents from one project with documents from the other one, just like 
> that the "foreign" documents would be treated just like any other 
> document not present in the project.
> 
> Do you like this? If not, how was the multiple project handling 
> imagined?

Working on multiple projects in parallel should be as easy as possible,
this means no extra activating it for example. Most stuff that works on
project base would be either in the mentioned Projects menu or only in
the context menu for that project. For example the Subversion menu we
have currently, needs to go completely.

> > Don't get me wrong, I'm not fighting a war against bringing back
> > currentProject, but I'd like to have some real good reasons to do so.
> 
> This real use I was trying to show in the mail. :)

Yeah, but as Alex said to me yesterday: but i don't want to do that
before it's really really needed (for making QDockWidgets visible
outside Sublime Ui library). So I'd rather try to see wether we can find
a way to work without current project.

Andreas

-- 
Don't relax!  It's only your tension that's holding you together.




More information about the KDevelop-devel mailing list