Bug 3212

Summary: Option to hide backup files as well as dotfiles?
Product: [Applications] dolphin Reporter: Unknown <null>
Component: generalAssignee: Dolphin Bug Assignee <dolphin-bugs-null>
Status: CONFIRMED ---    
Severity: wishlist CC: alejandro_aero, alpeterson, alvaro.aguilera, angel_blue_co2004, Beckmann.Maik, bugzilla, cooling.crystals, d.comtesse, darkadmiral, desintegr, dr, faure, felix, florian, flying-sheep, g4mba5, gabrielperren, kde.bugzilla.2012, kdebugs, kde_bugzilla_2, kfm-devel, kishore96, mail, maninalift, Marcin.Kasperski, nick, nicolasg, peter.penz19, postix, public, ricardo, sausageandeggs, ted, toby, toddrme2178, vascom2, wagnerluis1982, widiland
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Other   
Latest Commit: Version Fixed In:
Attachments: This is a patch to allow you specify glob patterns for hidden files

Description dgwatson 2000-05-05 16:19:20 UTC
(*** This bug was imported into bugs.kde.org ***)

Package: konqueror
Version: 1.9.2 (KDE Almost 2.0 Alpha)
Severity: wishlist

It would be nice if you could hide backup files (files ending in ~ or #).  This would make working with a large number of files much easier.
Comment 1 Andrey Cherepanov 2003-04-11 10:19:02 UTC
I need this option too. KOffice generate a large number of annoying backup files (anybody 
know how to disable this KOffice behavior?).  
Comment 2 Sashmit Bhaduri 2003-11-10 06:19:29 UTC
The problem, as I see it, is that there is no standard backful file suffix, at least in the same sense that dotFile are standard.
Comment 3 Drew Vogel 2003-11-10 07:13:14 UTC
So why not implement it as a regexp; hide all files that either match or don't match the regexp. That way I could specify ".+(~|#)", or something similar.

Then again, we'd make most people happy by hiding just .+~
Comment 4 Michael Jahn 2004-09-15 11:47:03 UTC
*** Bug 79248 has been marked as a duplicate of this bug. ***
Comment 5 Marcin Kasperski 2004-09-15 11:53:08 UTC
Bug 79249 suggests creating and applying some common convention for the backup file names....
Comment 6 Stephan Binner 2004-10-03 23:28:32 UTC
*** Bug 90568 has been marked as a duplicate of this bug. ***
Comment 7 Luke Sandell 2005-01-22 08:38:47 UTC
I actually hacked the Konqueror/KFileDialog code to do this (except it had the ability to hide any file matching a glob,  not just backups, and I'll make a patch against CVS when I get around to it.
Comment 8 Aaron Könsgen 2005-02-16 11:31:02 UTC
I had a similar idea and posted two example screenshots on kde-look.org: http://kde-look.org/content/show.php?content=20803
Comment 9 Sebastien 2005-02-16 15:01:02 UTC
I think it's a good idea too!

Then, I would also be able to hide those hideous ~/evolution/ and ~/tmp/ folders !!!

So, it would be a filter, not regarding only to the filename but also to the entire path (as I wouldn't want ~/Projects/evolution/ for example).
Comment 10 benjamin isant 2005-02-16 18:33:19 UTC
I vote for it
If it does in a clean way, what should allow to hide
-> files or folders
-> according to full path
-> OR according to the name, with respect of regular expressions (*.tmp etc...)

It could make Highly Incompetents Users (HUI) feel better on their mandrake-like distro without annoying purists.
It could also prevent my mother (she barely understand what's a file) to go and get lost in /usr, /etc, /proc etc...
without renaming all system-related files, starting with a point ...

BUT We have to keep in mind this is dual to the known convention "starting with a point is a hidden file". Which is hard to apply to system files ...
Comment 11 Luke Sandell 2005-03-20 05:02:01 UTC
Created attachment 10208 [details]
This is a patch to allow you specify glob patterns for hidden files
Comment 12 Luke Sandell 2005-03-20 05:03:16 UTC
OK, here is my patch, and AFAIK it works. You can now control what files are hidden with a list of globs under the [KDE] HiddenFiles key in kdeglobals, or if that key does not exist (it won't in your case) then it uses the default ".*". It does some weird things like deprecate the KFileItem::isDotFile() in favor of a new isHiddenFile() (because it is now not just dot files) - I hope this does not offend anybody. In my kdeglobals, for example, I have "HiddenFiles=.*,*~". Note that this patch only changes what files are hidden; it does not add any GUI element to configure it, but if that is desired, I will add it as well. I hope this gets committed as it is my first patch ;-).
Comment 13 Luke Sandell 2005-03-20 05:06:22 UTC
Oh yeah, one more thing: this patch only deals with file names, it is not suitable for hiding paths such as /usr. If you want to prevent your mother from browsing anything except her home dir, look into KIOSK maybe, I don't know.
Comment 14 Aaron Könsgen 2005-03-23 16:39:35 UTC
That sounds interesting. But how do I apply it correctly?
The following command (executed in the kdelibs directory with the patch inside) doesn't do anything.

patch -p0 patch.diff

Can anybody help? Thanks!
Comment 15 Luke Sandell 2005-04-11 02:28:45 UTC
Don't execute it from inside the kdelibs directory. Go one level up (e.g. the directory that contains the kdelibs directory), and then execute it. Note: this is more or less a quick hack, it won't necessarily work everywhere, but it would be good to get some feedback.
Comment 16 Nicolas Goutte 2005-08-06 19:57:49 UTC
I do not think that patch #10208 is the right way.

First hidden files are hidden files and backup files are backup files. A user might want to see the hidden files but not the backup files for example when he tries to edit some of them or on contrary he may only want backups to recover a backup.

Also I do not know why it is needed to redefine what a backup file is, as backup files have the mime type application/x-trash .

Have a nice day! 
Comment 17 Luke Sandell 2005-08-07 16:36:49 UTC
>A user might want to see the hidden files but not the backup files for example when he tries to edit some of them or on contrary he may only want backups to recover a backup.<

That's why it's configurable! Use the HiddenFiles= entry in kdeglobals. For instance, I have HiddenFiles=.*,*~
Comment 18 Nicolas Goutte 2005-08-07 17:01:43 UTC
On Sunday 07 August 2005 16:36, Luke Sandell wrote:
> >A user might want to see the hidden files but not the backup files for
> > example when he tries to edit some of them or on contrary he may only
> > want backups to recover a backup.<
> That's why it's configurable! Use the HiddenFiles= entry in kdeglobals. For
> instance, I have HiddenFiles=.*,*~

I meant to have such things in Konqueror's menu (in file manager mode). I will 
not edit a file for having the backup files for a few miniutes.

Have a nice day!
Comment 19 Luke Sandell 2005-08-09 02:06:00 UTC
>A user might want to see the hidden files but not the backup files for example when he tries to edit some of them or on contrary he may only want backups to recover a backup.< 

Well, there can only be one definition of a "hidden file." Either we are going to include backup files or we are not (a nice way this dilemma could be solved is by just including a dot at the beginning of the backup file).

What you are talking about is a way to show and hide certain types of files at certain times. That is a View Filter (see under the Tools menu), and Konqueror has those as well. Unfortunately they are not very versatile at this time.
Comment 20 peter_s_d 2005-08-09 09:00:56 UTC
Is the suggestion that all application should (optionally) save backup files as "dot whatever tilde"?  Or that Tools -> View Filter should be extended to include "don't show files matching pattern...."?  Or both?  Or something else again?
Comment 21 Toby Dickenson 2005-08-09 09:50:02 UTC
> A user might want to see the hidden files but not the backup files
> for example when he tries to edit some of them or on contrary he
> may only want backups to recover a backup.
There are several places in KDE which already have a 'show hidden files' toggle.... For example File Chooser dialog and KDevelop's file chooser sidebar. I think it is important that whatever mechanism we use for 'hiding' backup files should be toggled by that same control. That is inconsistent with the requirement quoted above.

An alternative design....
How about including a "hidden file" flag in the mime-type definition. Include a checkbox on Konqueror's file association configure page. I personally would check that box for application/x-trash and application/x-python-bytecode.
Comment 22 Nicolas Goutte 2005-08-09 12:38:49 UTC
On Tuesday 09 August 2005 02:06, Luke Sandell wrote:
[bugs.kde.org quoted mail]

MS Windows has anyway a totally other way of thinking about hidden files and 
that is quite different than a file name starting with a dot. That I also a 
reason why I would prefer not to mix the two things together.



Have a nice day!
Comment 23 Nicolas Goutte 2005-08-09 14:23:29 UTC
On Tuesday 09 August 2005 09:50, Toby Dickenson wrote:
> > A user might want to see the hidden files but not the backup files
> > for example when he tries to edit some of them or on contrary he
> > may only want backups to recover a backup.
> There are several places in KDE which already have a 'show hidden files'
> toggle.... For example File Chooser dialog and KDevelop's file chooser
> sidebar. I think it is important that whatever mechanism we use for
> 'hiding' backup files should be toggled by that same control. That is
> inconsistent with the requirement quoted above.
> An alternative design....
> How about including a "hidden file" flag in the mime-type definition.
> Include a checkbox on Konqueror's file association configure page. I
> personally would check that box for application/x-trash and
> application/x-python-bytecode.

Now (independently of this issue) there was a change in KIO to let the KIO 
slave control that a file is hidden or not.

That probably means that the isHidden() should not be changed in its meaning.
(And probably the patch does not apply anymore.)

Have a nice day!
Comment 24 Maksim Orlovich 2005-08-19 19:00:30 UTC
*** Bug 111101 has been marked as a duplicate of this bug. ***
Comment 25 Jakob Petsovits 2006-01-17 15:17:36 UTC
For the record, I proposed a different mechanism for backup files to get rid of the clutter in Bug 120313.
Comment 26 Stephan Sokolow 2006-12-10 22:06:40 UTC
I'd like to throw in my vote for Nautilus-style .hidden files, perhaps by merging the existing Kubuntu patch which adds such to Konqueror and KDE file dialogs.

While setting up Kubuntu for my brother, I noticed that they had used .hidden to clear out most of his root (I believe it only contained home, media, and usr) and, despite being a very technical person, my first thought after realizing how it was done was "What a great idea." for the following reasons:
1. .hidden can be customized folder-by-folder
2. No effect on my rootly duties since they're done through a terminal window.
3. Already supported by all my GTK+ 2.x apps. One file works for both.
4. Less clutter means less searching as I bounce around the filesystem.

It has it's flaws. For example, it can't be set on a per-application or per-user basis, but I think those are outweighed by the fact that it's already supported by GTK+ 2.x and Nautilus.
Comment 27 Tommi Tervo 2007-04-05 08:14:26 UTC
*** Bug 121195 has been marked as a duplicate of this bug. ***
Comment 28 Elmar Stellnberger (AT/K) 2007-05-07 16:34:21 UTC
Implementing the proposial at #142091 would probably be the best way to fix this !!
Comment 29 Elmar Stellnberger (AT/K) 2007-05-07 16:34:49 UTC
Bug 142091
Comment 30 FiNeX 2008-06-26 16:07:54 UTC
*** Bug 153881 has been marked as a duplicate of this bug. ***
Comment 31 FiNeX 2008-06-26 16:09:40 UTC
Like ppenz suggested to me, this is related to kdelibs. If implemented it could be used by dolphin (the current file manager).
Comment 32 David Faure 2008-06-26 18:21:40 UTC
Unfortunately, making everything configurable isn't a solution to every problem; it bloats the configuration dialogs or introduces hidden config keys which only solve the problem for the 5 users in this report.

I do see the need for a way to hide backup files and other such unwanted files [but let's not talk about hiding entire directories in this bug please, that's unrelated].

The purpose of backup files is that users _know_ they are there, to recover a document after a crash or a wrong deletion or overwriting of a document. Therefore they should not be hidden by default, unlike dot files.
So this means a possible solution would be to have "[X] Show backup files" in addition to "[ ] Show hidden files" (separate, because enabled by default).
This brings me back to Peter: what do you think about this? I know you might not like yet-another-menu-item... (and I'm not sure it's the best solution either).

Well I guess another solution is improving the dirfilter plugin, but then it'll be konqueror-only, no option in dolphin. That's a possibility though, if Peter prefers to keep Dolphin simpler (less configuration).

Note for comment #1: you can configure koffice so that it puts all backup files into a single directory, no more pollution of the real user directories.
Comment 33 Peter Penz 2008-06-26 18:31:55 UTC
@David: I'm not sure honestly speaking about this issue. I don't think the solution is yet another menu entry "[ ] Show backup files". E. g. the next request might be "please also allow to hide Amaroks *.m3u files" or "Digikams *.db" files.

What might a nice solution would be providing a general filter string per directory. This could be stored inside the .directory entry and filtered on application side. So we would have a generic solution that does not only work for backup files. Any thoughts?
Comment 34 Gerd v. Egidy 2008-06-26 19:05:19 UTC
@Peter: if you mean a regex operating on filename (basename) with "general filter string" this would be a great solution for me, solving all my needs.
Comment 35 Brandon Thomson 2008-06-26 19:11:36 UTC
filter string sounds good to me; simple and powerful.

there is nothing to stop an interested party from making a simple gui editor for the filter string in a separate window at a later date that helps less capable users choose which types of files they want to hide. that way you can avoid cluttering the main window with checkboxes and options as desired.
Comment 36 Stephan Sokolow 2008-06-26 23:53:53 UTC
Has anyone considered just adding support for obeying the .hidden file that Nautilus already supports? I think Kubuntu even has a patch for that.
Comment 37 David Bailey 2008-06-27 01:41:57 UTC
Some information about the Nautilus .hidden file:


Another option might be extended attributes so that the fact that the file is hidden becomes metadata of the file, and moves with the file if it's moved, for instance.

Comment 38 Stephan Sokolow 2008-06-27 02:41:01 UTC
Extended attribute hiding does have it's benefits as any Windows user knows. It IS nice to be able to hide a file without renaming it and, in the process, confusing any application which depends on it.

However, I'm sure there are arguments against it to. I haven't considered it, so I'm currently in "either would be fine" mode.
Comment 39 Stephan Sokolow 2008-06-27 02:48:15 UTC
Aha! One argument I didn't consider (since I use KDE with one or two GTK+ apps) is that a sane ~/.hidden implementation would be cross-compatible with Nautilus, thereby reducing hassle for integrators and any users who, for whatever reason, like to use both Nautilus and DolphinPart.
Comment 40 gambas 2008-06-27 11:31:02 UTC
That is really something I do not understand: why storing directory view information inside the directory itself???? 

It makes only sense when this view is the same for every user reading the directory. Otherwise, it is a bad design.

"Hidden" files, backup files I don't want to see, icon view, list view, background color... All these things that define the way the user want to see a specific directory, should be stored outside of that directory, in some sort of user-specific database or configuration file.

This mechanism should not prevent of using .directory or .hidden files, provided that it is clear that these files define the view for all users.

My two cents.
Comment 41 Brandon Thomson 2008-06-27 12:32:36 UTC
Another issue (as noticed on MacOS X a while back with their .DS_INFO files) is that they can expose valuable info to an attacker when web or other types of file servers are improperly configured to serve them them. When all the metadata is stored in the user's directory and has a consistent set of permissions this is less likely to happen.
Comment 42 David Bailey 2008-06-27 15:33:25 UTC
From my perspective, I really don't like the store-the-file's-extra-attributes-in-another-file approach. It's complicated to handle and keep updated when the files are renamed or moved.

I think the best approach would be two-fold.

1. Use an (xattr) attribute of the file to determine whether its hidden or not. A user can bring up the individual file properties and set this attribute. This is a good solution for a file-centric approach that transfers the attributes with the file when copying to other disks/systems, etc.

2. Use a regex pattern list ala adblock, both globally-defined for the system, for example any file starting with a dot, as well as user-defined for the user, for example I don't want to see any filename~ files. This is a mass-effect approach that is system/OS-centric. The user configuration can override the system global configuration for users who don't want their dot-files being hidden.

With #2 implemented, it wouldn't be that hard to add support for including other files, if they exist, such as a .hidden file. For example: "#include ~/.hidden". However, I'd like to re-emphasize keeping a separate list of individual files is not an elegant way to do this. It would simply be included for compatibility reasons.
Comment 43 Gerd v. Egidy 2008-06-27 17:57:53 UTC
I agree with gambas: hidden or not hidden is not something you want to have per file or per directory but it is per view. Each user can decide which view he wants to use where, even two different views in different windows at once.

So I think it makes sense to store a filter regex in a central, application specific configuration. Konqueror e.g. should store the filter regex in its "view profile" to make it easy to switch between views.
Comment 44 David Bailey 2008-06-27 22:18:24 UTC
I fail to see the purpose of saying, it's okay if a file or folder is hidden if it has a dot in front of it, but otherwise, it's a bad thing. All the leading dot is in the Linux context is a file attribute that has the side-effect of changing the file name. This is very similar to Windows file extensions. Changing the name, such as ending in .txt or .exe, changes the file type. Frankly, the fact that you can't configure this leading-dot=hidden-file/folder seems to exude UNIX-quirkishness to me. (Yes, I made up a word.)

Frankly, I think developers or system administrators should have the option of hiding individual files or directories without leading periods in the filenames if they want them hidden. Of course, users should also be able to view hidden files or folders if they choose. If we're in the business of hiding ad-hoc files or directories, it makes sense that that metadata be stored in an extended attribute (xattr) rather than in a separate file. This is similar to if I add a dot in front of a file name and move it, I don't have to update a configuration file somewhere to keep it hidden.

My #2 sounds very similar to your ideas Gerd/Gambas, except that there would be two levels. One which is a system-wide filter list, which BTW already exists as a de facto standard through leading-dot-filename=hidden-file/folder notation. This could be implemented as a global configuration file which empowers the system administrator at the expense of the user, or perhaps a set of default user settings. (i.e.- This is what most users want hidden, but you can change this.) The latter approach leaves the user in charge but makes it hard for the system administrator to role out a new file-hiding standard. This may be a good thing or not depending on your perspective.

Finally you would certainly also have a per-user configuration set of filters that could work as a view as you stated Gerd.
Comment 45 Stephan Sokolow 2008-06-28 00:26:29 UTC
My main worry with a filter regex is that it could get unwieldy very quickly and, depending on how it's implemented, could be useless anyway.

For example:


Imagine how that would look as the number of special-case files like ~/StepMania grew. As for "useless", it's utility depends on being able to match against the entire path... which is rather unlikely in a well-designed system.

Hence why I think that, if there is a filter regex, it should be in addition to something based around xattrs or .hidden. I do agree that, if it's going to be "done right", xattrs are the way to go. However, keep in mind that per-view hiding is outside the scope of the .hidden design since it's basically a way to duplicate Windows' familiar "Hide a file without renaming it" ability.

While I do agree that renaming files to mark them hidden is a quirky hack and as bad as using extensions to identify files, I don't like the idea of a system-wide filter list at the expense of the user. I envision all sorts of problems because applications could start basing their filenames on the most popular hiding regexes, resulting in confusion for users with non-default ones. Therefore, I think it'd be best if anything global was an /etc/skel-ish default rather than being an actual runtime-checked config setting.

In short, I suggest this:
- Per-user filter regex (perhaps stored in a DE-independent /etc/skel-able file)
- System-wide xattr-based hidden file attribute (Possibly with a .hidden compatibility mode)
Comment 46 David Faure 2008-06-28 01:53:16 UTC
Well it doesn't have to be -one- regex, consider that we could have a configurable list of hidden files patterns.
(Most users know patterns like *.bak more than real regexps like .*\.bak)
So a solution could indeed be a configurable list of patterns, like .*, *~, *#, *.bak, *.db, *.m3u  (the comma is just
for this mail; graphically it would appear like a list box with 6 items and add/remove buttons).
I guess it solves my use case of "using a backup file even though it's usually hidden", since the user could
simply toggle "Show Hidden Files" temporarily for this.
Comment 47 Toby Dickenson 2008-06-28 11:07:24 UTC
The "configurable list of patterns" idea has nearly come full circle to my suggestion in comment #21 that it be based on mime types. application/x-trash ("Backup Files") already comes with a fairly long list of patterns including *~ and *.bak
Comment 48 peter_s_d 2008-06-28 12:49:40 UTC
The more that I think about this the less I like it.  

Should hiding be an operating system thing, a filing system thing, an installation thing, a (creating) application thing, a (viewing) application thing, a view thing, or a user thing?  Or some evil combination of the above?  We could have a hierarchy of configurations.  >:->  There must be a dozen places that you can insert "vi" options.  

Option A)
"ls" already has "-a" and "-A" options.  Let's just badger all application maintainers to create dotted backup files.  

Option B)
Keep the current drop down menu "View".  Replace, "Show hidden files" with a sub menu, "hide files =>" and have a check box for each of; dot files, bak files, tllde files, [[every other daft convention that you can think of]] and finally a check box for a user's regex expression.  The default should be to have "dot files" checked and all others unchecked.  

Just my 2 cents worth.  ;-)  
Comment 49 Dean Serenevy 2008-06-28 14:35:43 UTC
Mostly in response to #48: Presenting a view of the filesystem that facilitates easy file management is the role of a file manager. A flexible mechanism to ignore a particular set of files helps out in this ares considerably. Whenever I launch konqueror to organize a directory I must first delete all of the stupid files (for me this is more than just backups, LaTeX generates a large number of auxiliary files that just clutter up the view). Disk is cheap, cleaning out these auto-generated files every time I want to organize my content is annoying and gets in the way of doing actual work.

To me, both supporting the existing .hidden approach and a configurable list of globally applied "backup" patterns (or globs) [I would vote for a separate "[X] Show backup files" menu item, but would be nearly as satisfied if they were all lumped together as "hidden" files] meet an appropriate expectation level for power users and could be made sufficiently obscure to avoid annoying individuals who do not want this feature. A general "filter contexts" submenu would be a nice general solution, but that is probably over the top and would get in the way of users who are not interested in using it so I am not pushing for that.

In summary: Several of the commenters here were interested in hiding non-backup files. Even if all application developers could be convinced to make their backup files dotfiles, this bug would not be fully resolved since that would not cover all of the desired usage patterns. It is useful and appropriate for a file manager to implement a feature that cleans up the user's view of the filesystem. Perhaps a better title for this bug is "Option to hide clutter as well as dotfiles".

Thanks for listening to my rant.
Comment 50 David Bailey 2008-06-28 18:29:54 UTC
I'm with Stephen on his conclusions and with David Faure on the point that you don't want a single regex, but a list of regex expressions.

I also like Toby's idea that we could store the hidden file regex list as part of the file-type/mime-types list. What's also good about this approach is that it is defined at the system level, but users can customize, so it empowers the users by getting around the idea of users being at the developers leading-dot preference whims.

So that would mean you could right-click on the file, get the properties of any file you have rights to, and hide (xattr) it.

Or, you could right-click a file, select the file type definition, and check a box to hide all files of that particular type. You could also create a new file type to cover any special "filename pattern" or regex and hide those as well.

The first way is a file-by-file system approach that is portable, between filesystems supporting xattrs. The second way is a user preference approach.

The only downside is that you don't get the flexibility of having multiple views that you could quickly switch between to hide different sets of files. Can anyone think of why that would be a desired function?
Comment 51 Stephan Sokolow 2008-06-28 19:15:28 UTC
On a well-organized system, I can't really think of a clear benefit to multiple saved views. Perhaps as a way to switch between viewing different types of files in a source tree, but that tends to be easily done using the filter box.

The main benefit I can think of would be for organizing an "unsorted junk" folder full of stuff that you let build up... but even then, setting "sort by type" and/or using the filter box (possibly with a split view) seem to solve the problem perfectly well.
Comment 52 Geoff King 2008-12-31 02:21:04 UTC
I'm trying out kde4.2beta2 and like the implementation in the desktop folder > folder view settings > filter > hide files matching....  Very useful. Something like this in dolphin would be great.
Comment 53 Chris 2009-01-09 04:43:16 UTC
Another possibility could be that, like KOffice, backup files could be optionally rerouted to a set folder.

Thanks for pointing the folder view hide files thing out, Geoff. I too hope that functionality will come to Dolphin.
Comment 54 Angel Blue01 2009-04-09 19:03:06 UTC
Couldn't this be resolved with .hidden files per this issue: https://bugs.kde.org/show_bug.cgi?id=64740 ?
Comment 55 Stephan Sokolow 2009-04-09 20:02:19 UTC
.hidden files are useful, but they don't let you say "Hide files which match this pattern ANYWHERE ON THE FILESYSTEM". (You'd need to create and maintain a .hidden file for every directory on your system)

This is about a global pattern ignore list. .hidden files are directory-local pattern ignore lists.
Comment 56 David Bailey 2009-04-10 14:15:18 UTC
Regarding my earlier comments in #50, of course, the user would have an option in the interface to "show all hidden files", and thusly switch between the view that hides the files marked (xattr) as hidden, and the file types (mime) option which are hidden.
Comment 57 Christoph Feck 2009-06-10 01:35:21 UTC
*** Bug 195767 has been marked as a duplicate of this bug. ***
Comment 58 FiNeX 2009-07-29 23:59:07 UTC
*** Bug 201678 has been marked as a duplicate of this bug. ***
Comment 59 Christoph Feck 2009-08-20 21:43:03 UTC
*** Bug 204428 has been marked as a duplicate of this bug. ***
Comment 60 Aaron Peterson 2010-07-13 04:29:07 UTC
That is a good point,
Applications create backup files so that users can find them.

Backup files clutter the enviornment for users.

Regarding the argument: yet-another-menu-item ... [ to twiddle a setting few people care about]
We don't need a menu option, IF there is a global kde settings editor, like firefox's about:config.  Is there such a thing? and can we make it?

.hidden file compatibility with gnome would be nice.  Does this work by having a list of files in it?

Extended attributes support would be nice,

regular expression method to hide files would be nice too (we have a filter to SHOW files,, why not have a negative filter too?)

Basically, lets just get the features and not worry about the GUI configuration, it should be handled in a glob of other configuration info.
Comment 61 Todd 2010-07-13 16:25:46 UTC
I think the last thing we want is a hidden config options editor like about:config, gnome settings, or regedit.  I think it a bad approach and once we set the precedent we will end up with a lot of untested, unstable, hard to find, and hard to understand options (like we have in all of those cases).  Hidden options should be hidden only because they are known to be incomplete, unstable, working poorly, or no one has found a good place for them yet.  Options that are intended for people to use normally should be properly organized.
Comment 62 Aaron Peterson 2010-07-25 08:33:55 UTC
A general, configurable, with memory of configuration(for context (which folder), application, and global settings) File hiding filter.

If I get a build environment up, I'll start playing with your patch. (need somebody in Seattle area who can figure out how to make kdesrc-build to work)


 Then these should be properly tested options only, It can't hurt to
 have another way to do stuff.
 It works for firefox--hidden was the wrong word. --
 Less floofy --mostly text-- managed-- method to configure options that
 people would otherwise have to search tab by tab to find.

 This about:config like configuration method would allow us to have
 options that power users need, and make it so that people don't file
 20 million feature requests for the same feature--they can find
 it--problem solved once and for all.

 So, In short, I agree fully that proper organization is important, and
 a column in the table could explain what it does, and there should be
 error checking on these configs.  I fould find this easier to use than
 tabs or editing config files. Telling people to edit config files is
 much worse than telling them to edit the list view of the options.
 Starting to feel bad about continuing here, Will file new request.
Comment 63 Nick Elliott 2010-11-02 10:52:57 UTC
I'd like to add my support for the original request (over 10 years old now - impressive!).
Comment 64 Philipp A. 2011-02-01 12:05:18 UTC
i want a glob list of file/folder names and paths to hide.

this way i can hide the stupid folder in my home directory, whose path is hardcoded in some stupid application (let’s call it appX), and this way i can hide all backup files, no matter where they are.

the file would then look like this:
Comment 65 Ricardo Graça 2011-02-23 23:35:01 UTC
This is the oldest bug/wish I've cast my vote on :D Fortunately I really like History! I came here after finding that there is no way in dolphin to hide those annoying (but usefull) backup files that keep poping up all over the place.

PS: Hello visitor from the future ;)
Comment 66 Gabriel 2011-12-14 13:18:37 UTC
I too ended up here after looking for a way to do this.

A user here http://forum.kde.org/viewtopic.php?f=17&t=82350 gives a workaround:

Settings -> Configure Kate... -> Open/Save -> Advanced -> add "." (dot) to "Prefix" under "Backup on Save".
Comment 67 Vasiliy Glazov 2012-04-24 08:01:16 UTC
Very bad bug.
Comment 68 Sam Tuke 2012-12-01 15:13:14 UTC
I'd really appreciate it if somebody worked on this; it's an extremely annoying bug.
Comment 69 Felix Widmaier 2015-11-28 09:04:23 UTC
Three years later and no news to this? Would be really great if this would be fixed.