Bug 186283

Summary: filtering by filename doesn't work properly in folder view plasmoid
Product: plasma4 Reporter: doc.evans
Component: widget-folderviewAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: asraniel, shantanu
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu Packages   
OS: Linux   
Latest Commit: Version Fixed In:

Description doc.evans 2009-03-06 01:04:36 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Ubuntu Packages

I have a directory (call it A) that contains a number of *tex files, along with many others.

1. Instantiate Folder View plasmoid on the desktop
2. Configure it to display the directory A

All files in A are visible. So far so good.

3. Open configuration and set it to:
  3a. Show Files Matching
  3b. File name pattern: *.tex
4. Click OK

The plasmoid shows no files at all; not even the ones that are of the form: *.tex

Actually, one can simply set the pattern to: *, which should presumably show all files, but still none are shown.
Comment 1 Shantanu Tushar 2009-03-08 17:18:23 UTC
Regarding this -
Note that if you have selected "Show Files Matching" or "Hide Files Matching",
only the files matching BOTH the conditions will be shown or hidden respectively.
For example, if you have "*" as your pattern, but have nothing selected in the MIME types, no files will be shown.

I understand that this is unclear from the interface, hint for this will be provided in the future.

Regards
Comment 2 doc.evans 2009-03-08 22:05:41 UTC
Oh, man.

I urge you to rethink this, for the following reasons:

1. Does anything else in the world work this way? I have never seen a name filter that also *requires* file type information.

2. Names in principle have nothing to do with types. I realise that for most people, most of the time, they do. But that's merely convention.

3. What does one do if a file has no associated MIME type? 

I'm not trying to do anything except point out that, as a user, this seems very (very) bizarre.

Just as an example (not made-up; this is perfectly real): 
  right now I have a file in a directory. The file has a name, but I have not the slightest idea what the MIME type is (nor indeed how to find out what it is). Nor do I care what its type is. All I know is that I want it to be the only file that appears in the plasmoid. From your description, there is no way to do that -- yet this scenario is the *exactly* the one in which I have a use for this plasmoid).
Comment 3 Shantanu Tushar 2009-03-09 09:17:37 UTC
Here, I would like to inform that we've working on this, and will provide a solution that is more intuitive. For example, one solution can be allowing user to choose from "Filter" or "MIME" or both by using checkboxes. As a feedback, will this seem ok to you, as a user?

>> 3. What does one do if a file has no associated MIME type? 
I've done a bit hit and trial on this, and whatever I did, the file was assigned some mime type, normally a text one. But true, the possibility remains.

>>Just as an example (not made-up; this is perfectly real): 
...
...

If you want to only display the files matching your criteria (e.g. Foo*.txt) just select all the MIME types, and then only the files that match your criteria will be shown. Any other files won't be shown even if its MIME is selected.
Comment 4 doc.evans 2009-03-09 16:47:17 UTC
(In reply to comment #3)
> Here, I would like to inform that we've working on this, and will provide a
> solution that is more intuitive. For example, one solution can be allowing user
> to choose from "Filter" or "MIME" or both by using checkboxes. As a feedback,
> will this seem ok to you, as a user?

Yes, that would be ideal.

> If you want to only display the files matching your criteria (e.g. Foo*.txt)
> just select all the MIME types, and then only the files that match your
> criteria will be shown. Any other files won't be shown even if its MIME is
> selected.

I don't know why I didn't think of this workaround. Thank you.
Comment 5 Beat Wolf 2009-12-07 15:26:15 UTC
i think this is fixed at least from kde 4.3 on