Bug 245994

Created attachment 49597 [details]
preliminary patch - it compiles at least :-)

testing may well be necessary :-D

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 ..]

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.

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.

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

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 ;-)

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

> 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

> - 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

> 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.

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?

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

> 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 ;-)

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

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