Getting the current active project

[Matthew Woehlke]

Andreas Pakulat wrote:
> 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.

Sorry... what I meant was it is sitting on some big NFS file server in 
another state, which is only *mounted* (for performance reasons) by 
other machines in /the same/ state. So for the local machines to access 
these files it must be done over e.g. ssh/sftp.

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

It might be useful but I like the 'local cache' idea better, that way 
your project is still stored "centrally".

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

My thought was that you "own" your project, any changes made from 
elsewhere just get clobbered. Especially since the general consensus 
seems to be that projects should not be shared anyway. :-)

My main thought with the async (in which case slowness wouldn't matter) 
was more to push changes out in case something catastrophic (like, say, 
a power failure) happened to your local machine, so that less would be 
lost. But it was just an idea, not something I think is "necessary" by 
any means. :-)

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

Ack! Hehe, yes that would be good, it is my favorite plugin. :-)

Some day I need to get a KDE4 development environment set up, but it is 
probably not going to happen this week. :-(

-- 
Matthew
Vs lbh pna ernq guvf jvgubhg fbsgjner, lbh ner n FREVBHF areq! -- 
Nqncgrq sebz Znggurj Jva (ivz-qri znvyvat yvfg)