KDE/kdevelop/buildtools/managers/custommake

[Andreas Pakulat]

On 01.06.07 13:07:53, dukju ahn wrote:
> 2007/6/1, Andreas Pakulat <apaku at gmx.de>:
> > 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 give only KUrl to projectmanager, then each projectmanager should
> calculate the corresponding Project**Items again, which is inefficient.
> Situation becomes more worse when we delete a big directory.

Sigh, you still don't understand what I want. I want to have a class
that works mostly like QFileSystemWatcher, but emits a few more signals.
That way certain parts of QFSW-using code don't need to be rewritten all
over kdevelop (or KDE at some point). This class then of course needs to
work on plain KUrl's, not project items. You're current ProjectWatcher
class can either move to lib/project (or rather kdevplatform/src/project
in 3 days) or stay inside makebuilder.

> Personally, performance should be the topmost goal to accomplish --IMHO

Thats not really correct, our topmost goals are bug-freeness,
feature-completeness (whatever we define as that). If those two are
achieved we can look at making certain things faster if they are too
slow. Optimization by guessing is baaaad. IMO.

> > > 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.
> 
> So what we want is totally different thing :). Within KDevelop,  I can't imagine
> any use case except than projectmanager.

Well, think about notifying when files are changed outside of KDevelop.
QM will need that to notify the user.

> Anyway, the key is how to determine whether some file is created/deleted,
> inside watched subdirectory. I think its hard without the aid of Project*Item.

No its completely easy: When a dir is added collect a list of
contained entries (easy with QDir), then when you get the changed signal
you check the new list against the old. We can use QSet here or QHashSet
which should be pretty fast at finding the difference between the two
lists.

> I'll try it anyway after I go over some other things in KDevelop. We have
> so much impending jobs..

Yeap.

Andreas

-- 
Stay away from flying saucers today.