project tree watcher interface plan

[Andreas Pakulat]

On 05.06.07 12:36:28, dukju ahn wrote:
> > > You misunderstand. I ask why each manager requires it's own file watcher
> > > class, when it's not needed. Handling these FS notifications can be done in a
> > > build manager specific way with just signals and slots , or by having the
> > > build manager implement an interface. Or even better, just have the build
> > > manager do its own thing with regard to file system watching.
> > >
> > > IMHO, after thinking about it more, this is not a problem that requires a
> > > platform based solution.
> >
> > I object - partly. While I do agree that having a file watcher on each
> > manager or each project is not needed I think its good to have a
> > directory watcher in a central place so that the managers are not
> > required to re-invent the wheel here. I don't have a patch at hand, but
> > I'm thinking of something like a QFSWatcher inside the projectcontroller
> > and the controller sends out signals for new or removed files (or calls
> > the manager slots directly).
> 
> Please note that  the main feature of suggested class is that it stores
> Project**Items in hash table when we call QFSWatcher::addPath().

I know (although I didn't look into the patch deeply)

> So that when we get filesystem notification,  we can easily retrieve
> corresponding Project**Items.
> Just having a general watcher is insufficient. One of the goal is to
> synchronize Project**Items with actual disk file.

I didn't mean a general watcher here, I was talking about a QFSWatcher
instance in the projectcontroller which can as well work with
Project*Items.

Anyway, I already agreed with Matt that for now the managers should each
have their own watcher (if needed) and if there's something in common we
can move it later on into the platform.

Andreas

-- 
Never look up when dragons fly overhead.