Getting the current active project

[Andreas Pakulat]

On 31.03.07 21:51:42, Andras Mantia wrote:
> 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.

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. 

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

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.

> > 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's a signal for project-opening emitted, including the project that
wsa opened. 

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

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

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

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

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

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

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

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. 

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.

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

I rather see a need for Build selected projects and similar stuff, then
1 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.

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.

Andreas

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