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