Version: (using KDE 4.4.2) OS: Linux Installed from: Unlisted Binary Package Steps to Reproduce: 1) Open a file dialog in a KDE application (say, an Open File dialog) which has a filetype filter (say, ".h"), and browse to a folder which contains multiple files, some of which do not match the filter. 2) Start typing in the file name field, so that the autocompletion feature is activated. Expected Behaviour: Autocomplete should suggest files in the current directory which match both your input and the filetype filter (in this example, C/C++ headers). The set of suggestible files should also correspond to the files which are shown in the dialog. Actual Behaviour: Autocomplete suggests anything which matches the input, regardless of filetype. In fact, in doing this, it will suggest files that are not shown, *and* cannot actually be selected at all. For example, I came across this while trying to open a header file without a .h extension in a dialog that filtered on said extension; it was a valid header, but even though KFileDialog suggested it, it would not let me open it. (That's probably a *good* thing, but the lack of feedback had me confused for a few moments) Reproducibility: Always.
Created attachment 42765 [details] Picture of the bug manifesting itself
You may use the Filter: right*.h RETURN
"You may use the Filter: right*.h RETURN" I'm not sure what you mean...
Created attachment 42870 [details] How to use a filter http://doc.qt.nokia.com/4.6/qregexp.html see Wildcard Matching
filter with blank (OR): a* b* files like: aha OR blabla The name field with auto completion is still useful.
I know what regular expressions are, and how filtering works; I was pointing out that having files that are not valid in the context (/and/ don't show up in the file list view) appear in autocomplete is confusing, and I can't see any good reason for it. I'm not complaining about problems developing with KDELibs, but rather reporting a user-visible problem (as I see it). My assumption was that the bug resided in the KDELibs file dialog, as I was able to reproduce it in several applications. If I'm wrong about that, please correct the report, and if there's a good justification for the autocomplete behaviour, please enlighten me.
Maybe there are some c files/folders in current folder ? Name: c I use the Name field just for info [in]dependent of the actual filter. Filter steps: a* -> a* b* -> a* b* c* This is an example where the behavior makes sense. "Name" relates to current folder. "Filter" relates to the shown file list.
multi level filter with "find" in console: > find . -name "*.cc" -a -name "hint*" | sort Find in the current and sub folders all "*.cc" files AND only those starting with "hint".
Works for me in KDE Frameworks 5.45.