project tree watcher interface plan
Andreas Pakulat
apaku at gmx.de
Tue Jun 5 15:24:15 UTC 2007
On 05.06.07 09:49:00, Matt Rogers wrote:
>
> On Jun 5, 2007, at 9:42 AM, Andreas Pakulat wrote:
>
> > On 05.06.07 08:14:03, Matt Rogers wrote:
> >>>>
> >>>> 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.
> >
> > 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).
>
> Except that by centralizing this functionality in the platform, the
> managers lose the freedom to do what they want to do with the file
> system watcher. For example, in CMake, I don't want to watch just the
> files or directories of the project, but I also want to watch the
> build system support files so that the project manager is robust
> against outside changes.
You mean watching /usr/share/cmake-2.4/Modules here, right? (as an
example)
> We can always move or add new things to the platform later but we
> can't remove things. Let's have the build managers do their own thing
> and then when we start to see a huge amount of functionality
> duplicated, then we can move it into the platform.
......... Hmmmmmm ...... Ok, I'm convinced,dukju: keep your
implementation in the make manager.
I will, nevertheless work on an extended QFSWatcher for kdelibs.
Andreas
--
You are the only person to ever get this message.
More information about the KDevelop-devel
mailing list