Community
Participate
Working Groups
Build Identifier: M20100211-1343 The Export Preferences dialogue has a dropdown box offering to show files meeting these two criteria: 1) *.epf 2) *.* Although I understand that Windows convention is to label filenames with their filetype, this is not convention on Linux. For instance, I name my preferences file eclipsePreferences with no "dot/period" character, i.e. no filename extension. Please revise the *.* option to be simply *. Thank you. Reproducible: Always
I think this work was done as part of bug 88905, changes to at least 3 places. See bug 89726 for the last discussion, although more focused on .* *.* wasn't able to find my prefsCvs file, which means you have to type it manually into the import dialog. To fix this though we would need to make sure that a filter of "*" worked on windows, mac, and linux. PW
Ideally, the platform-dependent functionality would be in the file chooser dialog. It is not a big deal to add "*" filer to this dialog. But then Windows users would fine it very odd. Plus, this will be inconsistent with all other file chooser dialogs I can think of (File -> Open File, File -> Export to Archive File) to give a couple examples. The only reasonable way I can see here is to have the file browse dialog treat "*.*" as "*" on Unix.
Bug #88905 is interesting, it implies that the preferences file should have had an .epf extension by default. It didn't, I would have changed the name but not the extension. However, that is a related but separate issue, as files with no extensions should still be shown. Bug #89726 does seem to be a specific case of this bug. I am tempted to mark this one as a dupe, but as this bug discusses the more general case I am leaving it open. > The only reasonable way I can see here is to have the file > browse dialog treat "*.*" as "*" on Unix. If that would be the case, then I recommend changing the text to "Display All Files" or "All". I would consider that a fix, at least for the Linux platform. I should note, however, that in my specific use case I had exported the file from my Linux machine, to import in the Windows machine at my college. So a Linux-only fix would not solve all real-world use cases.
(In reply to comment #2) > The only reasonable way I can see here is to have the file browse dialog treat > "*.*" as "*" on Unix. Let me see if I understood it: do you want SWT to replace "*.*" by "*" on gtk/motif ?
(In reply to comment #4) > Let me see if I understood it: do you want SWT to replace "*.*" by "*" on > gtk/motif ? To me that seems like a reasonable way to resolve this issue. Not being an expert, I am sure that there are more details to iron out: - if no extensions are specified, I think dialog assumes "*.*" - I like the Dotan's suggestion of using label "All" instead of "*.*", but that bring a question of if it will show hidden files and what to do with explicitly specified "*.*" in the filter. That said, the question is how much work & potential to disrupt this change will be vs. the benefit. Are files with no extensions still commonly used on Linux?
> Let me see if I understood it: do you want SWT > to replace "*.*" by "*" on gtk/motif ? _I_ would like that, but not everybody would! That would show hidden files as well, which is not a problem in subdirs but will be a mess in $HOME. I just took a look at the Gedit File Chooser Dialogue (that's the correct term for the open/close dialogue I think). It's dropdown box specifies "All Files" and "Text Files". Additionally, the main widget context menu (right-click menu) has three options, one of which is to hide / show hidden files. I would recommend simply copying that familiar, tested, and consistent-across-applications dialogue. I can post screenshots if needed. Update: I just looked at the Thunderbird save dialogue and although it is not identical to the Gedit dialogue, the features discussed in this bug are in fact identical.
This has been resolved in the GTK file choose for awhile. Closing this bug accordingly.
