Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Hidden directories can'r be opened in Linux|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||CLOSED NOT_AN_OOO_ISSUE||QA Contact:|
|Priority:||P3||CC:||ahz001, elish, issues, kpalagin, lohmaier, mey.wer|
|Version:||OOo 2.0 Beta||Keywords:||oooqa|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
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
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
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?