project tree watcher interface plan

[Matt Rogers]

On Tuesday 05 June 2007 00:24, dukju ahn wrote:
> 2007/6/5, Matt Rogers <mattr at kde.org>:
> > On Jun 4, 2007, at 9:43 AM, dukju ahn wrote:
> > > Apart from the general wrapper around QFileSystemWatcher, what
> > > I want to discuss here is specific project tree watcher which
> > > targets project managers.
> > >
> > > Although we can use the general wrapper discussed, I think that
> > > using general wrapper for project managers is duplication of memory
> > > usages. The key to project manager tree watcher is that it should
> > > stores
> > > Project**Items for each watched path. And it can compare difference
> > > using that project**items.
> > >
> > > So my plan is that the "general" wrapper around QFSWachter will not
> > > be used for projecttreewatcher.
> > >
> > > Also, rather than emitting signal, my plan is that we have base class
> > > named "projecttreewatcher", and provides virtual interfaces, because
> > > we can provide some default implementations. Especially,
> > > directoryCreated() and deleted() implementation would be common
> > > among the project managers, since makefile parsing event will be
> > > taken place in fileCreated() deleted() modified() method..
> > >
> > > Any objection?. I expect as before.
> >
> > Why does each build manager need its own file system watcher?
>
> Because when filesystem are changed, appropriate actions should
> be taken by project manager again. For ex, if new directory which
> contains Makefile is copied, the manager should parse() it again.
> So each manager just reimplement the virtual method.
>

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.

> > IMHO, We should have one file watcher for each project.
>
> I didn't say that the watcher will be created for each manager.
> Yes. the watcher should be initiated for each project. And it is the
> manager that creates watcher.
>
> > This could be
> > provided by the shell. The file watcher passes signals or send events
> > (i think i'd prefer events here) indicating what has happened on the
> > file system.
>
> I'm against sending event. Why do we have to define addition event
> for each happens? If each manager use their own watcher for each  project,
> the problem becomes simpler.
>
> Also, event is slower than direct calling. Please note that when we delete
> a directory which contains 5000 files, then directoryChanged() signal will
> be emitted 5001 times.
>
> >The build manager then takes that information and does
> > whatever it wants/needs to do with it.
>
> If each project manager reimplement the given virtual method, the same
> thing can be done.
>

And virtuals have high costs associated with them. When necessary, I like to 
avoid virtuals, and this is one of those cases where I think we can avoid the 
extra virtuals by having the manager create its own instantiation of 
QFileSystemWatcher and using that and dealing with it directly.
-- 
Matt