KIO::listRecursive() with filters

[David Faure]

On Friday 30 October 2009, Milian Wolff wrote:
> Wow, been some time :) 

Yeah. Too much email...

> We ported KDevelop to mutliple listDir() calls now,
>  put together in a ComposeJob or how it was called.

Ah.

> > 1) The simple one, adding a KIO::ListJob::setExcludedFilenames(const
> > QStringList&)
> 
> Woudln't this break BC?

Please read the BC page on techbase ;-)
Adding non-virtual methods is perfectly fine.

> > 2) The more flexible one, adding a "hook" where the application can
> > define which files to exclude. Actually... thanks to Carsten Pfeiffer I
> > have some class doing this kind of stuff on my harddisk... Attached.
> > Needs to be integrated into ListJob and then tested, of course ;)
> > IIRC he wrote it for kde3, but it was never used anywhere, so it was
> >  cleaned up for kde4, but I kept a copy for a day like today.
> >
> > (Note that KDirLister has this kind of functionality already, with a
> >  virtual bool matchesFilter, but this won't help the fact that the
> > listjob recurses into unwanted directories; the dirlister filtering
> > happens after the fact).
> >
> > In fact, Carsten's idea was to port KDirLister to that KFileFilter class
> >  (but given the virtual stuff, that's for KDE5 now, I guess). At least
> > this gives a good plan ahead: in KDE5 we can use that filter class from
> > both ListJob and KDirLister (doing it in the listjob isn't enough for the
> > kdirlister use case, since it lets the user change the filter at runtime,
> > e.g. when showing/hiding dot files in the file dialog, and we don't want
> > to re-list the directory at that point, so I think both uses are needed).
> 
> Yes, the class looks good. When a pointer to it can be passed to the
> listRecursive e.g. I could overload passesFilter for my needs. Or would you
> think it should go into the mainline:
>
> What is always / often lacking from filters like the one here, is that it
>  only matches against the _name_ of the file (ok, and mimetype and stuff,
>  but that's not my point). Problem with matching name only, is that you
>  cannot match stuff like "dir called foo" (when matching against path
>  simply add filter for "foo/"). Or "file called bar somewhere in path XYZ".
>  For KDevelop/Quanta I added this, since I find it sometimes useful to have
>  such kind of filtering for projects.

Yeah I think when it gets to complex rules, it becomes hard to express them
in a generic kdelibs filter -- we'd end up with some slow query language !?

> But of course, it's arguably whether one would need such stuff anywhere
>  else.

Yes, same thoughts here.

I think kdelibs should have the virtual base class and the "simple filter"
derived class from the files I attached, while more complex needs would
be app-specific. Until of course 2 or 3 apps realize that they need the same 
but not before --> the usual rule for putting stuff in kdelibs.

> But: How can I make KIO::ListJob use KFileFilter without breaking BC (see
> above)?

The non-virtual "setFileFilter()" will be fine BC wise.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).