project tree watcher interface plan

Matt Rogers mattr at kde.org
Tue Jun 5 14:49:00 UTC 2007


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

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.

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






More information about the KDevelop-devel mailing list