Getting the current active project

[Andras Mantia]

Hi,

 At this moment it is not possible to find out what is the active 
project inside KDevelop. In Quanta we need to know the current project 
in the following places:

1) User toolbars and actions. This is an important feature of Quanta and 
something which can be very useful for KDevelop itself as well. An user 
can create its own action and group its own actions (and also standard 
supplied actions) on toolbars. The toolbars can be saved/loaded/shared 
via KNewStuff or email. With the help of these toolbars it is very easy 
to associate different actions to different XML or script languages. 
When the user switched from a document holding HTML to a document 
holding DocBook, the HTML toolbars are unloaded and the DocBook 
toolbars are loaded.
 The actions themselves can be simple things like insert/replace some 
text in the current document (thus there is a need for know which is 
the current document) or they can execute a third party application (or 
shell script), for which it is possible to supply standard arguments, 
like the path to the current file, the name of the current file, the 
path to the project, so the application/script can work on these files 
(eg. reformat them, replace something inside them, or do whatever it 
wants). See 
http://docs.kde.org/stable/en/kdewebdev/quanta/user-actions.html#script-actions
for details.

So what to pass to "%projectbase"? I see two solutions:
- provide (again) a way to reach the active project
- provide a way to know to what project does the active document belong

Probably having both would be the best, as if we have only the second 
solution, there will still be a problem if for example there is no 
active document, but the user is looking at a help page.

Due to the nature of these actions (that they are grouped on toolbars), 
I don't think it is feasible to put them in project context menus or in 
the main menu. They are more language (and document) specific, but 
project specific. 

2) Similar to the above, but for KParts, Quanta had the possibility to 
use ANY KPart as a plugin. Usually KParts get an KUrl as an argument, 
and this argument could be the path + filename of the current document 
or the path to the active project. An important use case was 
integrating kdesvn as a plugin. The kdesvn kpart did not exists at the 
time Quanta was created and the user (and we, the developers) didn't 
have to code anything in plus, the only need was to configure the new 
plugin with the path to the current project and everything worked as 
expected. Some other KParts are used in a same way (klinkstatus, 
kfilereplace, konsole, kimagemapeditor), some of them take the project 
path, others the current file path as an argument.


3) Through the code we use a class called QuantaNetAccess for file 
operation (copy, move, delete, create). The idea is that the class 
always checks if the operation affects or not the project, and it asks 
the user to delete/add the files to the project or not. Again, this 
needs a way to find out what is the current project.
Here other approaches could be taken, like:
- monitoring all opened project folders and notifying the user if there 
was a change there. Problem: how will this work with remote projects?
- iterate over all the projects and do the check for each and everyone. 
Problem: slower, more compilcated code.

Thereby I request to introduce back the notion of the current project in 
the KDevelop platform.

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