KDE/kdevelop/buildtools/managers/custommake

[Andreas Pakulat]

On 01.06.07 16:06:56, dukju ahn wrote:
> 2007/6/1, Andreas Pakulat <apaku at gmx.de>:
> > On 31.05.07 13:58:35, dukju ahn wrote:
> > > Rather than emitting removedEntries(), having virtual interface is more good.
> > > This virtual interface will be called instead of emitting signal.
> > > And each managers just implement their own removedEntries() and somthing.
> >
> > But then the Watcher class is bound to the project manager, I was saying
> > that it should be a more general-purpose wrapper around
> > QFileSystemWatcher to provide more fine-grained signals (instead of
> > directoryChanged the user of the class is notified when files are
> > added/deleted). This is something that will be used elsewhere in
> > KDevelop.
> 
> It can't be separated from projectmanager. It uses Project*Items to determine
> whether some file/dir was created/deleted or not.

Of course it can, you just have to add some more logic to the class. You
have the source, nothing is impossible.

> Moreover, connecting its signal from other component is unsafe. For ex.
> when the files/dir are deleted, QList<ProjectFileItem*> is given
> as an argument. ProjectManager will delete that from model. Then, other
> component recevies already deleted pointer and it segfaults.

The class shouldn't use Project* stuff, it should use KUrl::List.

> If we need signal for other componenet than project manager, we can
> have each project manager emit signals inside that virtual interface. Only
> after proper operations are taken, the signals can be emitted safely.
> And other plugins get the pointer via IProject::watcher() or something.

No, this has nothing to do with Project stuff, I want a more convenient
QFileSystemWatcher, I'm currently thinking that we may be able to move
that into kdelibs if its working properly as a replacement for the
unmaintained KDirWatch.

Andreas

-- 
Avoid gunfire in the bathroom tonight.