project tree watcher interface plan

[Matt Rogers]

On Jun 5, 2007, at 10:24 AM, Andreas Pakulat wrote:

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

That is one example, yes. :)

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

Thanks. An extended QFSWatcher for kdelibs to replace KDirWatch  
sounds like an excellent idea.
--
Matt