Getting the current active project

[Andreas Pakulat]

On 31.03.07 22:48:31, Andras Mantia wrote:
> 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. ;-)

But to which one should KDevelop switch? It could switch to the first in
the list, to the one before or after the closed on (in the list) or to
the last one. How do we choose? Which will confuse people the least?

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

Somehow this sounds very much like scripting support and we plan to
support one of the possible scripting libs (Kross or QtScript at the
moment)

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

I understand your worries and I've seen the problems. However _if_ we're
going to write KDevelop4 and KDevPlatform, we're not going to do such
major reworks anymore. Its the same as with the rest of KDE: We need to
get out of tinker mode. What the platform still lacks (apart from
various little things here and there) is a review of the VCS API,
language support (including a generalized DUChain) and profile support.
Everything else is done at least "direction-wise". OTOH if we don't get
out of tinker mode soon (that includes me btw) we won't ever release
KDevelop4 and can just go ahead and do KDevelop5.

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

Well, Eclipse by default does automatic building in the background and
that is quite ok. However this will not work very well for KDevelop I
think, as C++ is quite different from java.

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

Especially the commit thing I do quite often @work in Eclipse. There we
have 2 webapps and 2 base libs for the webapps and changing something in
the base lib needs changes in the 2 webapps and I can select the 3
projects and commit all at once. All this while having 3 other projects
with difference open that should not be committed. Thats why you can't
just select the root node to commit.

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

There's no active project? Although I don't think Alex would like this
(he won't write any mails today, he takes a day off). I hope he can
catch up with the two of us tomorrow.

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

Depends, if there's no selection yet it makes sense to automatically
select the opened project, but if there is already a selection that
would be quite annoying.

Andreas

-- 
Good day to deal with people in high places; particularly lonely stewardesses.