Getting the current active project

[Andras Mantia]

On Saturday 31 March 2007, Andreas Pakulat wrote:
> It currently is before and right after opening the first project
> (until the user clicks into the projectmanager view). It will also
> happen after closing a project (not sure if that works atm at all).
> In the 2nd case there are still projects, just no "current" project.

That is just implementation detail to switch the active project after 
closing one. ;-)

> Yes, knowing if and which project a given open document belongs to is
> on my todo list. Part of the API is already there, all that is
> missing is the one in projectcontroller that iterates over the open
> projects.

That's great. I have to think about a case when we need to know the 
project and there is no document opened yet (the example I give is 
similar, but there as you said, we can get the project path from other 
sources), but until I find a real case having only this might be a 
solution.

> > I have a script action which is executed when the project is opened
> > and changes the ownership of all project files to a specific one.
> > This behavior was needed to make possible working in a team without
> > using a version control system on the production server (which has
> > the http server running).
>
> There's a signal for project-opening emitted, including the project
> that wsa opened.

The idea here is that the user is free to do whatever he wants with such 
actions and execute whenever he wants. In Quanta (again something I 
want to port to the whole KDevelop) it is possible to assign ANY action 
(including the user defined ones) to certain events, like opening 
project (this is what you wrote), saving a file, closing a project and 
such. The user might want to do something with the whole project when a 
file is opened or saved, for example. 


> > There might be other actions as well working with %projectbase, but
> > i'd need to do a deeper search, as the actions are in .tar.gz file.
> > ;)
>
> Ok, take your time. Re-Adding currentProject is just a matter of a
> few lines, so we can do that anytime we really need it.

Ok, I will let you know when I find something.

> Thats not decided yet. Build could build the current file, or the
> last project that was built. Or something completely different.
> Frankly I don't know at the moment and until we do a full freeze on
> the kdevplatform we can change anything anytime :)

To be honest this is what I did not like 6 months ago. It was still 
unclear where this all KDevelop goes. Now it looked better after 
reading Alexander's mail and I hope that this will happen sooner and 
not only at the freeze time. I mean, at least there should be some 
direction to go, otherwise this platform idea will just not work.
It was also the case at that time that we ported something, found some 
issues, updated KDevelop, realized that some things were removed or are 
not possible at that moment because they will be rewritten and we could 
choose if we change our code and try to follow the KDevelop idea, or 
leave as it is, broken, and wait to see what happens with KDevelop. 
Well, for multiple reasons the latter happened, and I hope it won't 
happen again. (This is not about the currentProject, just about my 
worries of how can we go on with the platfrom.)

> Eclipse does this using a drop-down toolbar item (with the last 10
> "things" that the user executed) and a more complex dialog available
> via the menu. You can define such "runnable things" completely
> independant of any project, you can define a dozen items for the same
> project and target (in case of C++ projects).


Probably I'd need to try Eclipse myself, but from what I heard 
(including this statement) and read, it seems more confusing than 
productive.

> Eclipse does this pretty well (IMHO), Build displays a dialog where
> you can check projects to build (those that are currently selected
> are enabled by default).

Ok, I'll install Eclipse. ;)

> Also such multiple projects allow for some things to be done easier:
> Committing to multiple related projects at once, by selecting
> multiple projects in the treeview and executing the commit. Or
> searching through multiple projects.

Is this really that common? Do we need to be able to select multiple 
projects at once to do one action on them?

>
> Actually this opens a new question: When I select multiple projects
> in the treeview, which one is active? I guess the last one as we'd be
> using the currentChanged() signal, but then build would build only
> the active one which is again unexpected - IMHO.

I think the only sane solution (if you really want multiple selection 
there) is that the active project is the one you work on. And this is 
defined by the active document. If you work on a document belonging to 
the first project and you think that meantime you can build the second 
project, you might select the second project from the treeview and 
build it, but as you still work on the document, the active project 
remains the first one. The other one is build in the background.
This tends to be the same as my second proposal: the active project 
changes when you switch between the opened documents. Question: what 
happenes if there are no open documents?

> I rather see a need for Build selected projects and similar stuff,
> then 1 active project.

Would it mean that the project you load is automatically selected, or 
you would need always to select (mark) the project after it is loaded? 

> Ok, we can change it when we need it (and I don't expect us to
> discover this after the .0 release) but for now lets see if we can do
> without.
Ok, so regarding this currentProject issue, lets try with finding out to 
what project the active document belongs to.

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/fb442371/attachment.sig>