Issue 55700

Summary:	Hidden directories can'r be opened in Linux
Product:	General	Reporter:	jlblom <jlblom>
Component:	ui	Assignee:	AOO issues mailing list <issues>
Status:	CLOSED NOT_AN_OOO_ISSUE	QA Contact:
Severity:	Trivial
Priority:	P3	CC:	ahz001, elish, issues, kpalagin, lohmaier, mey.wer
Version:	OOo 2.0 Beta	Keywords:	oooqa
Target Milestone:	---
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Latest Confirmation in:	---
Developer Difficulty:	---

Description jlblom 2005-10-09 22:22:46 UTC

I just discovered an annoying omission in OOo2.0 RC1.
I want in Linux to approach hidden directories (directories starting
with a dot (e.g. .evolution). However, the users guide doesn't give any
information (neither Help). Is it not possible??. Than I think its value
- for Linux users - is seriously diminished as many files (a.o.
databases and address databases0 are most often stored in hidden
directories. As Linux has a decent directory mechanism there must be an
explicit switch, preferably in the options menu, to set the display of
hidden files on or off.
In my opinion it is a serious bug.
Joep

Comment 1 aziem 2005-10-10 00:23:32 UTC

Using the built-in OOo open dialog (not the GTK), I can access hidden
directories by typing their name.  If I am in ~ and I want .evolution, I just
start typing .evolution in file name.  Then autocomplete finishes it.  Then I
type ENTER.

Comment 2 michael.ruess 2005-10-10 07:48:57 UTC

Framework issue.

Comment 3 jolatt 2005-10-10 09:53:24 UTC

Why is this a bug?
If you want to have access to hidden directories change them to unhidden.
IMO it's a matter of the operating system not of OOo.

Comment 4 jlblom 2005-10-10 21:04:36 UTC

I tested aziem's suggestion and I agree it works. However, it's not a real
solution as I must know beforehand, which directory I ant to use. If I for
example will look with OOo at some attachment that's saved in some  hidden mail
directory and I don't know which, I have a big problem as I don't know in which
it is saved. If I would like to use OOo to look at some hidden rc-file instead
of vi (textmode) or gedit (graphic) I can only look at it if I know the name. 
As I wrote to aziem, it is not a solution but a complicated way around an
omission whch I think is easily corrected.

Comment 5 lohmaier 2005-10-10 22:27:24 UTC

It is not a bug with GTK-filepicker.

There just right-click and select "show hidden files" or press <ctrl>+L and
enter the filename/directoryname starting with a . (the box does autocompletion).


OOo's dialog does autocompletion as well. 
So just start typing ".ev" and you will be prompted. You can cycle through the
proposals using the arrow-keys.

The directories are hidden for good reason. You usually should not need to mess
around with the files in these directories.

Since the native fpicker already provides a control to show/hide hidden files,
and you can access them through OOo's filepicker, I suggest closing this one as
Wontfix. (No additions to the options, no further functionality for OOo's dialogs).

Comment 6 thorsten.martens 2005-10-13 13:19:24 UTC

Not a defect, works as designed. Feel free to file a wish for an enhancement.

Comment 7 thorsten.martens 2005-10-13 13:33:18 UTC

Comment 8 rosspjohnson 2006-03-06 23:25:31 UTC

This defect issue should be reopenned and renamed to:

"OOo's user directory naming and file browser capability are incompatible".

OOo studidly names this as ".openoffice.org2" and then provides a filebrowser
that can't see it. I assume the same applies on Solaris.

So what does this affect?

- template editing via Files - Templates - Edit. Can't find 'em.
- various paths in "Tools - Options - OpenOffice.org - Paths" can't be found.
- lots of other stuff no-doubt but this should be enough to show that this is a bug.

E.g. User downloads a non-US dictionary. The wizard drops it into
~/.openoffice.org2/user/wordbook (or it should).
Now user want to use it so goes to "Tools - Options - OpenOffice.org - Paths"
Selects Dictionaries and clicks Edit. Gives up because it's not in the file browser?

The user should not have to type the filename - that assumes that they know or
can remember the filename. That is what the file browser is there for.

You are assuming that the average user (business person, clerk, secretary) will
type a folder or directory name into the "File name" box. Wrong - if they even
bother to do that much, and they should not be required to if the file already
exists, then they will type the file name part only and then start browsing the
folders via the icons, expecting to see only folders and/or matching file names.

Comment 9 kpalagin 2007-01-10 08:30:16 UTC

*** Issue 73313 has been marked as a duplicate of this issue. ***

Comment 10 kpalagin 2007-01-10 08:33:46 UTC

Reopening as RFE.

This problem exists on Windows platform too, if using OO.o dialogs, and it is 
compounded by the fact that there is no autocomplete feature.

Comment 11 thorsten.martens 2007-01-29 14:55:11 UTC

TM->requirements.

Comment 12 meywer 2008-08-05 14:27:02 UTC

Cloph wrote:

> It is not a bug with GTK-filepicker.

> There just right-click and select "show hidden files" or press <ctrl>+L and
> enter the filename/directoryname starting with a . (the box does 
> autocompletion).

I don't find a possibility to rightclick for an option "show hidden files" in
oo-open-dialogs.
So I see only the way via autocompletiton (as long as it works).

> The directories are hidden for good reason. You usually should not need to
> mess around with the files in these directories.

> Since the native fpicker already provides a control to show/hide hidden files,
> and you can access them through OOo's filepicker, I suggest closing this one 
> as Wontfix. (No additions to the options, no further functionality for OOo's 
> dialogs).

I would like an option to show "dot-files" too.

Comment 13 meywer 2009-09-14 21:21:05 UTC

Wondering about the fact also in 3.1.1 I still cannot open linux-hidden-directories.

-> cloph 
I dont find any possibility to change this behavior. Could you explain that?

Comment 14 Edwin Sharp 2014-02-23 20:02:36 UTC

comment 1 works.
AOO410m1(Build:9750)  -  Rev. 1566800
2014-02-11_04:11:01 - Rev. 1566981
Debian