Getting the current active project

[Andras Mantia]

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. I understand 
that remote projects doesn't mean too much sense for C++, but this is 
not the case when you don't have to compile the sources.

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

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

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

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

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.
2) in this case what will happen if the current document is not part of 
any other project.

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

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?

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

Andras



-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070331/6671ac5c/attachment.sig>