Getting the current active project

[Andreas Pakulat]

On 02.04.07 17:38:18, Matthew Woehlke wrote:
> Andras Mantia wrote:
> > On Saturday 31 March 2007, Andreas Pakulat wrote:
> >> Hmm, currently we don't because KConfig doesn't support reading from
> >> remote urls. I have currently no idea how we could make this work,
> >> except by copying the project file to the remote location after
> >> project closing.
> > 
> > That's the solution I also used in Quanta in some places. Store a copy 
> > of the file in a temp directory and upload when needed.
> > Not supporting remote projects is a showstopper for us. I understand 
> > that remote projects doesn't mean too much sense for C++, but this is 
> > not the case when you don't have to compile the sources.
> 
> Huh? Sure they do :-). It is common around here to have sources sitting 
> on NFS volumes in a different state, and do builds there.

Well, a mounted NFS volume is not a "remote project". Remote == ftp,ssh
or eventually even webdav.

> This, along with Andreas' point, brings up a thought that would be very 
> helpful here; if project files and source files didn't need to be in the 
> same tree (I forget, maybe KDevelop4 already allows this?),

Currently not, but it would be only a setting.

> or, better 
> yet, have a way to locally cache frequently-accessed files and/or files 
> that can't be remote (i.e. Andreas' point again) and push them out 
> either asynchronously in the background, and/or on project close.

Well, writing the configuration files back only on project closing is
one of the easiest and fastest solutions.

While writing back on configuration change seems "cooler", it may be a
problem, think of slow-links and also the IProject carries its own
KSharedConfig::Ptr to a local cache which would need to be re-fetched
from remote every time its accessed. The problem here is that there's no
easy notification possible between KConfigSkeleton (which would do the
reading/writing of configuration for the dialogs) and IProject.
Basically because they don't know each other and there's no 3rd object
that knows both.

> (*...and here's another good point; is it possible to port grepview to 
> somehow work with remote projects, or at least to work over sftp where 
> presumably it can be run in an ssh -c session?)

Uhm, first we have to port grepview to KDev4 ;)

Andreas

-- 
Abandon the search for Truth; settle for a good fantasy.