Bug 245994 - Add ability to hide individual files/folders - similar to effect of .hidden files
Summary: Add ability to hide individual files/folders - similar to effect of .hidden f...
Status: RESOLVED DUPLICATE of bug 246260
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-28 10:22 UTC by Mark
Modified: 2014-09-14 22:59 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
preliminary patch - it compiles at least :-) (5.69 KB, patch)
2010-07-28 19:16 UTC, Mark
Details
working patch (8.33 KB, patch)
2010-07-29 08:09 UTC, Mark
Details
update to working patch - include .hidden file list (9.80 KB, patch)
2010-07-29 20:10 UTC, Mark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark 2010-07-28 10:22:17 UTC
Version:           unspecified (using KDE 4.4.92) 
OS:                Linux

nautilus respects a list of files contained in a .hidden file in the current directory, hiding them;

as dolphin keeps its per-directory settings in .directory, it should be straightforward to add a StringList config setting such as HideSpecificFiles to the .directory;

longer-term, perhaps the .hidden files could be parsed into .directory for some consistency across file managers

Reproducible: Always

Steps to Reproduce:
create .hidden file containing the name of a file/folder in current directory
view current directory in dolphin / refresh


Actual Results:  
listed file is visible

Expected Results:  
listed file "should" be hidden
Comment 1 Mark 2010-07-28 19:16:43 UTC
Created attachment 49597 [details]
preliminary patch - it compiles at least :-)

testing may well be necessary :-D
Comment 2 Mark 2010-07-29 08:09:15 UTC
Created attachment 49620 [details]
working patch

needs some testing - my ssh kde environment was occasionally unhappy, although it had mime types difficulty so it may be a different cause :-)

It definitely works though :-D

set, for instance, .directory to read, under [Settings]
HideSpecificFiles=myfilename1[,mydirname2 ..]
Comment 3 Frank Reininghaus 2010-07-29 16:19:33 UTC
Thanks for the report and the patch! It's up to Peter to say if this feature should go in, but here are two remarks of mine:

1. Maybe it would be better to use the ".hidden" file to stay compatible with Gnome?

2. There is an earlier report about this issue, but for KDE 3's Desktop: Bug 64740.
Comment 4 Peter Penz 2010-07-29 16:42:16 UTC
Thanks for the patch, but personally I don't see a usecase for Dolphin's target user group for this feature and fear that it might make things more complicated than easier... How should the UI look like to hide specific folders? When making them visible again: Should there be a visual hint that this folder is hidden in general, but had been made visible temporary?

If it should go in, I agree with Frank that a .hidden file might be preferable to stay compatible with Gnome.
Comment 5 Mark 2010-07-29 20:10:45 UTC
Created attachment 49650 [details]
update to working patch - include .hidden file list

Hi, thanks for the comments both of you;

Frank, I notice from the comments to bug 64740 that .hidden is apparently more standardized than it had seemed, so I've been hard at work :-)

I've improved the behavior too, so that specifically hidden files are now viewable when all hidden files are visible;

Peter, looking at that list of comments, does that address your concerns? As it looks as though there's a considerable majority in favor of adding the functionality;

currently allows additional hidden files from the .directory file, the question arises would it need looking 'up the tree' for .hiddens? That may be more trouble than it's worth

Best regards

Mark
Comment 6 Peter Penz 2010-07-30 08:18:09 UTC
Mark, before investigating too much work into the patch: My concerns are not related to that implementing this is possible, my concerns are related which UI elements are required to make this feature useful (see my questions from comment #4). I don't want to add this feature to Dolphin and let the user manually to edit the .directory/.hidden file with KWrite ;-)
Comment 7 Mark 2010-07-30 08:49:19 UTC
Hi Peter,
so that raises further questions

1 have you got suggestions how to provide UI hints?
2 who do you think is the 'target audience' for dolphin? In a free democracy, the actual audience has priority; it would seem that the actual audience is composed of a mixture of people, as would seem natural;
3 as the comments to the kde3 bug say, there are several categories of people, some of whom are happy to manually edit .hidden/.directory files, some of whom have yet to hear of dot files at all, etcetera; for that reason, we tend to implement features as someone has the energy to implement them - in the present case that involves manual edit implementation - rather than insisting that they provide all kinds of additional features initially?

Either way, I know that some functionality is better than none, hence the reason I'm implementing it for myself; it would seem wasteful of you not to implement it for the community at large - not to speak of the PITA it is for me to replace the distro's binaries every time there's an update :-D

Best regards

Mark
Comment 8 Peter Penz 2010-07-30 09:50:49 UTC
> 1 have you got suggestions how to provide UI hints?

No, nothing concrete.

> 2 who do you think is the 'target audience' for dolphin? In a
> free democracy, the actual audience has priority; it would
> seem that the actual audience is
> composed of a mixture of people, as would seem natural;

See http://dolphin.kde.org/philosophy.html - it is impossible to satisfy 100 % of all users, so it is important to set priorities and to know for which target audience the application is optimized.

> 3 as the comments to the kde3 bug say, there are several
> categories of people,
> some of whom are happy to manually edit .hidden/.directory files,
> some of whom have yet to hear of dot files at all, etcetera; for
> that reason, we tend to implement features as someone has the
> energy to implement them - in the present case that involves
> manual edit implementation - rather than insisting that they
> provide all kinds of additional features initially?

One of the main tasks of a maintainer is to decide which features should go in and which not. If I'd add each feature to Dolphin that is requested or where a patch is available, Dolphin would not be usable anymore and would be an unmaintainable mess of various patches. I've read the comments, but:
- I don't see how this feature mets the requirements of the target user group of Dolphin
- The feature is intrusive as additional UI is required to allow users to hide files

> Either way, I know that some functionality is better than none,

That's not true in my opinion: Each feature results in new code paths that need to be maintained and in additional user interface elements that might clutter an application.

> hence the reason I'm implementing it for myself; it would seem wasteful
> of you not to implement it for the community at large - not to speak of
> the PITA it is for me to replace the distro's binaries every time there's
> an update :-D

I often get patches from people for Dolphin and I'm very happy about this. Still for most of those patches it ends the way that it's up to me to fix all related issues to those patches later. So it is important for me to decide whether a feature goes in like explained at http://dolphin.kde.org/philosophy.html
Comment 9 Mark 2010-07-30 11:05:16 UTC
> - The feature is intrusive as additional UI is required to allow users to hide
files

where do you get that from? No UI is 'required' at all, unless the notion of people editing their own .hidden files / the notion of dolphin respecting .hidden files from gnome generally that is at the very least a de facto standard seems contrary?

>> Either way, I know that some functionality is better than none,

> That's not true in my opinion

rather a stranglehold opinion in the face of a majority of comment :-D - it's not a codebase-cluttering kind of improvement at all, really I'm surprised at your obstructiveness
Comment 10 Peter Penz 2010-07-30 12:41:39 UTC
> really I'm surprised at your obstructiveness

Then I'll try to explain it from a more technical perspective: If this patch would be merged into Dolphin, this would result to the following bug-report "When using the file-open dialog, hidden files are still shown, although I've added them to the .hidden file and although I've disabled the 'Show hidden files' checkbox".

So if the .hidden file should be respected and no UI should be provided, then this should be handled KDE wide in my opinion (in this case probably by KDirLister I'd guess).

So just considering this from a technical point of view, this feature should not be implemented in Dolphin but in kdelibs in my opinion.
Comment 11 Mark 2010-07-30 12:57:44 UTC
Hi Peter,

well that's at least more straight talking :-)

it sounds potentially right that KDirLister should eventually implement respect for .hidden files;

Maybe I'll send them a patch :-D

now obviously my answer to that, is that it's for dolphin to implement it now, then for kde to implement it eventually, while in the interim you answer the bug report 'file open dialog behaves differently [ie at least de facto wrongly]' in the terms that 'file open dialog' is a different beast belonging to different people? Either way it would seem that hiding specific files from 'file open dialog' is less important than the actual filesystem browser itself.

Besides, once we notice that there is a de facto standard, then it looks as though not implementing it is more wrong than implementing it, doesn't it?
Comment 12 Mark 2010-07-30 13:13:10 UTC
ps as for the philosophy, there's not all that much in the real world to distinguish Simon from Jeff, although for age-group / number of monitors at least, I'm Simon :-D
Comment 13 Peter Penz 2010-07-30 13:46:05 UTC
> Maybe I'll send them a patch :-D

That would be great of course, but still I'd recommend to clarify with the corresponding maintainers of KDirLister whether they want to accept this feature. Otherwise you'll investigate a lot of work and might get frustrated if it gets rejected :-( Just a suggestion for the interface (e. g. should KDirLister::showDotFiles() be used or a new interface been introduced) and a short description how you'd implement it might be sufficient already.

> now obviously my answer to that, is that it's for dolphin to
> implement it now, then for kde to implement it eventually

I'd like to prevent doing this in Dolphin only, it just makes KDE SC as a whole more inconsistent doing it this way.

Personally I still doubt that this feature is really helpful, but I might be wrong with this opinion ;-)
Comment 14 Mark 2010-07-30 17:38:05 UTC
it's not that much work, really, for intelligent people :-)

patch to kde libs is already at bug #246260 - I look forward to well-reasoned views there :-D

I seem to read from your comments the 'fear of the new' factor that could be the reason you have persuaded yourself for 7 years that a feature the community demands is more work than you're willing to put in :-D

As I've already said, when there's a democratic vote in favor of a feature, then one person's opinion against that simply looks dictatorial - particularly in the absence of constructive alternative suggestions, the future is going to leave you behind; Me I'm already looking at putting my skills into the development of a different file manager now as your attitude seems particularly negative, I dare say I'm not the only one

There may be details of the implementation that may need a vote, that is no reason for not implementing it at all; neither is it particularly scary to need to change the detail :-D
Comment 15 Peter Penz 2010-07-30 17:47:18 UTC

*** This bug has been marked as a duplicate of bug 246260 ***