Getting the current active project

[Andras Mantia]

On Saturday 31 March 2007, Andreas Pakulat wrote:
> > > 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.

Than I don't understand when could the currentProject return 0.

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

Why?

> 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 ;)

In my original mail I suggested this "provide a way to know to what 
project does the active document belong". But this is neither 
available, and would need an extra step, but I don't really mind after 
all as I can write a helper method any time. Isn't what you are 
suggesting here?

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

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


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

This is good in theory, but what will happen with the shortcut keys? Do 
you always need to use the mouse or navigate through the menu to 
start/build/debug a project? Now I'm talking about developing C++ 
projects as obviously Quanta doesn't need to build the XML files. ;)

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

I never used Eclipse, so I'm not sure how this works. What happens if 
you have 2 projects, each defines such a "runnable" item (I assume this 
is what would be built with a shortcut) and load both projects at the 
same time. Which will be the runnable item?

> Thats called 1 project at a time and personally I don't want that. 

Yes, but in a managed way. You would not need to switch between two 
KDevelop instances, just between two projects inside KDevelop. ;)

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

Altough in this case there are other solutions (including the one with 2 
KDevelops), I can see some advantage, but it is still not clear for me 
how will a good UI work with multiple projects, especially without the 
notion of "active project".

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

I agree that this is a good way to handle multiple projects (context 
menus), which is kind'a similar to how multiple targets are handled 
inside one project, still I see a need for an active project.

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

I'm not convinced that we can work without, but for my use case probably 
knowing to which project the active document belongs would be enough 
for now.

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