project tree watcher interface plan

[dukju ahn]

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.

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