project tree watcher interface plan

[dukju ahn]

2007/6/5, Matt Rogers <mattr at kde.org>:
> 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.

What is build manager you mentioned? Is it different from project manager?
I'm confused by the terms.
I was saying that, for example, cmake manager would want to watch only
CMakeList.txt stuffs and automake manager may want to watch *.am.
So each manager initiate the watcher utility class, which only provides
common notification methods. And each manager do different thing on
notification slot( or virtuals, event handler whatever.. )

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

Please see my attached file. The file didn't propose that I will add additional
interface on IProjectFileManager. What I suggested was utility class which
will be initiated by project manager.