Hi,

I am pretty sure that not too long ago i was able to type a regular expression filter in Dolphin's filter bar (i think i was even using the pipe symbol to match multiple expressions).

Secondly i believe that suddenly a great feature turned up which matched folders regardless of the filter expression. In the "details" view you could then expand a folder and see if there were any matches to expression in that folder.

I am running KDE 4.4/Linux and believe the above was either during 4.4 or otherwise 4.3. Of course i could have just been dreaming, but i am pretty sure the above worked.

Did something happen there, am i missing something?

tx.,

Raphael

I just checked on my KDE 4.3 installation of Dolphin, and indeed, regular expressions are supported to a degree in the filter bar. I couldn't verify the folder content matching though.

This doesn't work in trunk though.

So what happened here? Are regexps possible? One thing I would like to do in the filter bar is frex to filter all .py files, but not the .pyc or .py~ files. In a regexp you would search for py$, IIRC, but that doesn't work in the filter bar (dolphin 1.4, kde 4.4.4, fedora 13).

Looks like this is fixed in 4.8.
But i'm using kde 4.10 (opensuse 12.3) and still can't use re in filter bar.

Is there any option to enable this? Or it's just not fixed?

By looking at source i can see that current implementation of RegEx support is almost usless

Indeed, that is quite unusual.
I suspect this was done to minimize the performance impact (as QRegExp can be quite expensive compared with basic string comparison).

If you have ideas on how to improve this, I would suggest mentioning them in a bug report, or creating a patch and publishing that on Reviewboard ( at https://git.reviewboard.kde.org )

Regular expressions are not supported at all. The code just checks if the filter contains *, ?, or [ and then uses "Wildcard matching", see

http://qt-project.org/doc/qt-4.8/qregex ... d-matching

I don't know why the wish report about regular expressions has been closed. But anyway, I don't see how we could implement regular expression matching without getting into conflicts with wildcards. * and ? also have a special meaning in regular expressions, so we cannot tell if the user wants to use wildcard or regular expression matching just by looking at the contents of the filter string.

Shouldn't it be possible to incorporate some two character symbol to indicate/enable a regexp filter similar to shebang(#!)? find an uncommon combo to start it off and if need be escape(\) it for regular wildcard filtering.