On 01.06.07 13:07:53, dukju ahn wrote:
> 2007/6/1, Andreas Pakulat <apaku gmx.de>:
> > On 01.06.07 16:06:56, dukju ahn wrote:
> > > 2007/6/1, Andreas Pakulat <apakugmx.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.
_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|