Community
Participate
Working Groups
3.1 I'd like to have an option to locate eclipse files on my disk more easily. Something like: you select a file/folder and do 'show in <OS-explorer-like-name>' and the OS specific file expolorer would open and show me the selected file.
We added this feature to our product, I'll see if I can pull it out and contribute it as a patch.
(In reply to comment #1) > We added this feature to our product, I'll see if I can pull it out and > contribute it as a patch. Any updates, Ken? My friend actually complained to me about this and I wrote a Windows-only solution for him. ;p It would be nice if there was something that worked on all platforms.
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
*** Bug 317161 has been marked as a duplicate of this bug. ***
When is this scheduled for inclusion?
(In reply to comment #5) > When is this scheduled for inclusion? It's a P5 with no target milestone, so..."not anytime soon". It is marked as 'helpwanted' so we would be willing to review patches if someone comes up with a good cross-platform solution.
This could be implemented by providing an org.eclipse.ui.editor that supports an external launcher. Have the launcher determine its platform and call the appropriate native exec to show the file in the native explorer (windows exp, nautilus, etc). PW
Would you also accept a patch that launches the terminal in the currently selected folder?
*** Bug 245019 has been marked as a duplicate of this bug. ***
I have External Tools launch configurations for the systems I use most often, but this should really be a "Show In > ..." target. I don't like the idea with an external editor, since this is a "Show" or "Reveal" action that will not open a selected file (but opens its parent folder). Windows: C:\WINDOWS\explorer.exe /E,/select=${resource_loc} Mac (only opens parent folder, does not select resource): /usr/bin/open ${container_loc}
*** Bug 344378 has been marked as a duplicate of this bug. ***
Created attachment 194657 [details] Azureus/Vuze 'showFile' implementation for MacOS X The bittorrent client Azureus/Vuze has a 'show in explorer' or 'show in finder' option, this is the implementation for MaxOS X.
Created attachment 194658 [details] Azureus/Vuze 'showFile' implementation for Win32 The bittorrent client Azureus/Vuze has a 'show in explorer' or 'show in finder' option, this is the implementation for Win32
(In reply to comment #12) > Created attachment 194657 [details] > Azureus/Vuze 'showFile' implementation for MacOS X (In reply to comment #13) > Created attachment 194658 [details] > Azureus/Vuze 'showFile' implementation for Win32 Are you the author of these files and am interested in contributing these files to Eclipse under the Eclipse Public License? If not, please do not attach code under the GPL to Bugzilla.
The Azureus/Vuze bittorrent client has a 'show in explorer' feature. To achieve this they use a platform specific implementation of a 'PlatformManager'. I have attached partial source of the MaxOS X and Win32 implemtations taken from their source code. They do not have a working Unix implementation, probably because there is no single default and universal 'explorer'-like application, but maybe it would be sensible to implement this for Windows and Mac first, which might already satisfy a reasonably large user segment. For Unix maybe one could consider adding a configuration option where the exact command to execute in place of 'show in explorer' can be specified, if that's not bordering on a different new feature altogether: to be able to show an external tool launcher in the 'show in' menu. Actually, come to think of it, having the ability to put any external run command into 'show in' might solve everything...
Sorry, hadn't considered the license conflict. If appropriate to delete, please do (or please tell me how).
I think we should just add an option to the Workspace preference page, where users can configure the command line to be used by a new "Show In > System Explorer" command. The preference default can then be initialized depending on the platform: Windows: explorer.exe /E,/select="${selected_resource_loc}" Mac OS X: /usr/bin/open -R "${selected_resource_loc}" GTK: <command that selects the resource in nautilus> The ${selected_resource_loc} can probably not use the variables plug-in, since this variable is only defined in the org.eclipse.debug.ui plug-in. But it can just replace this variable manually.
(In reply to comment #16) > Sorry, hadn't considered the license conflict. If appropriate to delete, please > do (or please tell me how). No problem. Thank you for your understanding, Thomas. I have emailed the webmaster to request that the two attachments be deleted.
The content of attachment 194657 [details] has been deleted by Eclipse Webmaster <webmaster@eclipse.org> who provided the following reason: GNU licensed code The token used to delete this attachment was generated at 2011-05-04 09:44:50 EDT.
The content of attachment 194658 [details] has been deleted by Eclipse Webmaster <webmaster@eclipse.org> who provided the following reason: GNU licensed code The token used to delete this attachment was generated at 2011-05-04 09:45:15 EDT.
*** Bug 351123 has been marked as a duplicate of this bug. ***
*** Bug 356738 has been marked as a duplicate of this bug. ***
*** Bug 363332 has been marked as a duplicate of this bug. ***
This is really easy under MacOS, call Runtime.exec("open -R "+path); That's the implementation at leasy, I don't know how difficult that would be to add to the context menu in the PackageExplorer.
It's should be very easy.. I think the problem is there is any patents problems?. It's was so useful and I was wondered no one implemented it.
No, it's not a patent or licence problem. Comment 17 tells how this should be fixed. The only problem is that nobody had time to write a good quality patch. Contributions are welcome.
Created attachment 235678 [details] First attempt towards implementing this I've taken a go at implementing this. Since this is the first time I'm writing anything for the platform ui, it probably violates several guidelines, naming conventions, etc. I'm going to post in the platform forums to seek guidance; there's several things I'd like to check, like: - does this need to go into the org.eclipse.e4 namespace? - e4-or-not, which plugin should I use? I've crammed everything into org.eclipse.ui.workbench for now - the defaults should be based on the host OS. I've set it to xdg-open for Linux. I could do some checks within the org.eclipse.ui.workbench to assign an appropriate default for linux, windows and macos, but should this be contributed by some architecture-specific plugin? (e.g. like SWT has features for each architecture).
(In reply to Alex from comment #27) > I've set it to xdg-open for Linux. With xdg-open, in case of a file, it won't be shown in the file manager (window with parent folder and the file selected), but instead launch it with the default application. That would be the same as Open With > System Editor. If being specific to GNOME is not a problem, the command to use would be this: nautilus --select "${selected_resource_loc}" A less specific option would be to use the org.freedesktop.FileManager1 DBus call: http://www.freedesktop.org/wiki/Specifications/file-manager-interface/ For example: gdbus call --session --dest org.freedesktop.FileManager1 --object-path /org/freedesktop/FileManager1 --method org.freedesktop.FileManager1.ShowItems "['file:///home']" ""
Created attachment 235686 [details] Take two I've changed the Linux default to the gdbus command. I think it's sensible to expect this to exist on GTK systems. I've also added defaults for Windows and MacOSX, based on the comments in this thread.
*** Bug 416483 has been marked as a duplicate of this bug. ***
(In reply to Alex Mising name from comment #29) > Created attachment 235686 [details] > Take two Hi Alex. Thanks for your contribution. There's some bookkeeping before I can review it. 1) update your bugzilla preferences with your name (right now it's "Alex Mising name" where appearntly missing is spelled wrong :-) 2) electronically sign your CLA (you can click the CLA icon after your name to get started). We review contributions in Gerrit now. See http://wiki.eclipse.org/Platform_UI/How_to_Contribute#Getting_the_code_into_your_workspace and http://wiki.eclipse.org/Platform-releng/Git_Workflows#Gerrit_workflow_for_a_committer If you sign your CLA I can push your first patch up to Gerrit for you. PW
I'll also mention please don't reformat any of the files you need to change. Thanks, Paul
Created attachment 235735 [details] New patch with this functionality Moved everything into org.eclipse.ui.ide as per guidelines given, with preferences in IDEWorkspacePreferencePage. Code still needs work to become production quality. Looking into org.eclipse.ui.tests.api now.
(In reply to Alexandros Karypidis from comment #33) > Created attachment 235735 [details] > New patch with this functionality Thanks Alex. I've pushed the fix to https://git.eclipse.org/r/16726 to be reviewed. PW
Created attachment 235825 [details] Patch which addresses the review comments This patch addresses all the helpful review comments in Gerrit (https://git.eclipse.org/r/16726). Please note that this applies on top of: https://git.eclipse.org/r/platform/eclipse.platform.ui refs/changes/26/16726/2
Hi Alex. Instead of attaching a patch, I need you to 1) make your changes on top of refs/changes/26/16726/2 2) add them to your git index 3) amend the previous commit (this will pull in the commit message that contains the existing Change-Id) 4) right click on the git repo eclipse.platform.ui and use Push to Gerrit... We're using refs/for/master PW
Alex, the patch is really good and almost ready to go. Thank you for your effort. Unfortunately, it throws exceptions on my system: !ENTRY org.eclipse.ui.ide 1 0 2013-10-04 15:47:44.710 !MESSAGE gdbus call -e -d org.freedesktop.FileManager1 -o /org/freedesktop/FileManager1 -m org.freedesktop.FileManager1.ShowItems ['file:///opt/pwebster/workspaces/runtime-e44/z.ex/src/z/ex/Activator.java'] '' !ENTRY org.eclipse.ui.ide 4 0 2013-10-04 15:47:44.714 !MESSAGE Show In (System Explorer): Unhandled failure. !STACK 0 java.io.IOException: Cannot run program "gdbus" (in directory "/opt/pwebster/workspaces/runtime-e44"): error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041) at java.lang.Runtime.exec(Runtime.java:617) at java.lang.Runtime.exec(Runtime.java:450) at org.eclipse.ui.internal.ide.handlers.ShowInSystemExplorerHandler.execute(ShowInSystemExplorerHandler.java:114) The more reliable command is probably: dbus-send --dest=org.freedesktop.FileManager1 \ /org/freedesktop/FileManager1 \ org.freedesktop.FileManager1.ShowItems \ array:string:'file:///opt/pwebster/workspaces/runtime-e44/z.ex/src/z/ex/Activator.java' But even this doesn't work on RHEL 6.4, it includes a version of nautilus that's too old (2.28). That version doesn't support --select either. The nautilus CLI expects folder URIs: nautilus 'file:///opt/pwebster/workspaces/runtime-e44/z.ex/src/z/ex/'
I've released your Gerrit change as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3bf83231daed635a149b9878c15a6ed83b93ea13 Thanks a lot for your work on this. I released http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=bdf481011d66fe44c59f199c171f2ec50ea3aecb to fix my problem on linux. But I don't think this feature is quite right yet. I've opened bug 418715 to talk about how it opens the parent of folders instead of the folder itself. If there are other aspects of this feature that need work, please open a new bug. PW
Fixed some UI bugs: - Bad command name in menus (requires bug 418836) - Preference page violated UI guidelines - Added "system explorer" as preference keywords - Didn't work at all on Windows. Fixed bad usage of regex replace in ShowInSystemExplorerHandler. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=83fa9c2e1bea835f2530836e6bf202b5f216dd95
Why are the ShowInSystemExplorerHandler_*DefaultCommand strings externalized? I don't expect these commands to need translation, and putting them in to a messages file just cries for bugs in translation packages. Products that want to override the commands should customize the preference value, not hack the translation. TODOs (these are basic requirements, not "other aspects" as per comment 38): - Don't write to the log unless there's an error. - On Windows, it looks like explorer.exe always returns 1, so this should not be considered an error. For well-behaved platforms (Mac, Linux), checking the return code is fine. - Externalize error messages in ShowInSystemExplorerHandler that are shown to the user. Use consistent wording (e.g. "System Explorer", not just "Explorer"). Dialog title should be the command name ("Show In System Explorer") and not an error description. - Don't externalize the system command strings. - Add documentation on the help page for the preference page. The help page must list the supported variables, since they are not otherwise discoverable. - Enable the command in the editor context menu (or at least make it invisible in the menu when not available).
(In reply to Markus Keller from comment #40) > TODOs (these are basic requirements, not "other aspects" as per comment 38): > > - Don't write to the log unless there's an error. > - On Windows, it looks like explorer.exe always returns 1, so this should > not be considered an error. For well-behaved platforms (Mac, Linux), > checking the return code is fine. > > - Externalize error messages in ShowInSystemExplorerHandler that are shown > to the user. Use consistent wording (e.g. "System Explorer", not just > "Explorer"). Dialog title should be the command name ("Show In System > Explorer") and not an error description. > > - Don't externalize the system command strings. Done with commit http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f407117266d9c1153ce3972fe9f2832f661de0b0 I used the StatusManager to open our standard workbench problem dialog replacing the 2 calls to ErrorDialog. PW
The code still had problems with paths containing spaces, caused by using the form of exec with a single String argument. Proposed fix with explanation: https://git.eclipse.org/r/17234
The menu item also needs an icon - being the only one without an icon looks ugly.
Created attachment 236346 [details] Fix using sh on Linux/Mac (In reply to Robin Stocker from comment #42) > The code still had problems with paths containing spaces, caused by using > the form of exec with a single String argument. Proposed fix with > explanation: > > https://git.eclipse.org/r/17234 This fix fails on Windows. I can't reveal files with a space in the path. The problem is that explorer.exe has very weird command line argument processing and the recent "fixes" in the JDK also didn't make things better (bug 387504 comment 13). If you just use a StringTokenizer to split up command parts, then you end up with two parts: - explorer - "/E,/select=C:\test\sp ace\file.txt" java.lang.ProcessImpl.createCommandLine(..) just concatenates these strings, but explorer.exe doesn't understand the "" around the argument. And your fix also fails on Linux/Mac if the path to the executable contains a space. To correctly use the multi-arguments API, we either need a very complicated UI where the user can enter a String[], or we need an OS-dependent command line parser. I think we should just use /bin/sh on Linux/Mac and keep exec(String, ...) on Windows.
(In reply to Markus Keller from comment #44) > This fix fails on Windows. I can't reveal files with a space in the path. > > The problem is that explorer.exe has very weird command line argument > processing and the recent "fixes" in the JDK also didn't make things better > (bug 387504 comment 13). That is indeed weird. > And your fix also fails on Linux/Mac if the path to the executable contains > a space. True. > To correctly use the multi-arguments API, we either need a very complicated > UI where the user can enter a String[], or we need an OS-dependent command > line parser. I think we should just use /bin/sh on Linux/Mac and keep > exec(String, ...) on Windows. Yes, passing the string to /bin/sh to let it parse it is also an option. I tested the patch on Linux and it works. The only problem I see is when the path contains a " character, \\, $() or other shell escapes. Imagine a path like this (including the quotes): "; rm -rf /pleasedonttrythis; "
(In reply to Robin Stocker from comment #45) > The only problem I see is when the path contains a " character, \\, $() or > other shell escapes. Thanks, I missed that. We need to quote the string. Furthermore, creating a URI by concatenating "file://" with a file path is doomed. We need a variable with the uri: ${selected_resource_uri} Here's an interesting file name (Mac's Finder renders ":" as "/"): :&();|<>\'"`!{}*@#?$ä -.txt Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d2522a0f7c9e02542543ceb2225617b006f6f0de Tested on all 3 platforms.
(In reply to Markus Keller from comment #46) > Fixed with > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=d2522a0f7c9e02542543ceb2225617b006f6f0de Looks good now! So the only thing missing is an icon now? How about something with a folder? The java working set icon without the J?
(In reply to Markus Keller from comment #40) > - Enable the command in the editor context menu (or at least make it > invisible in the menu when not available). There's still also this PW
(In reply to Markus Keller from comment #40) > - Enable the command in the editor context menu (or at least make it > invisible in the menu when not available). I've released a fix for this with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ce4ff8388d81c28fc8bdba33d8aabb3212429748 The menu item is still visible and disabled in certain editors. I've opened Bug 419853 for that. PW
(In reply to Markus Keller from comment #40) > - Add documentation on the help page for the preference page. The help page > must list the supported variables, since they are not otherwise discoverable. Added document to the Workspace preference page with http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=e04133deb77f4bcec26df8b7c7cf22efebe4893f I took the image of the pref page on linux, though, so we might have to redo it. So outstanding for this feature now is visibility (Bug 419853) and an icon? PW
> So outstanding for this feature now is visibility (Bug 419853) and an icon? Yup. But IMO, an icon is not really important. I would just go without an icon. All views have a specific icon that helps the user quickly find the view even in a longer list. But the actual System Explorer looks different on all platforms, so a single icon necessarily looks "wrong". The gap in the menu is not really a problem; it even helps in finding the System Explorer item. See also http://msdn.microsoft.com/en-us/library/windows/desktop/aa511502.aspx#icons Thanks for completing this, Paul. Marking as FIXED again.
In 4.4.0.I20131028-2000 PW
sorry to disturb, i want to request add show file/folder function in explorer at the Eclipse "Package Explorer" view, because some file is can not be opened in Eclipse editor, and some file are executable, so I want a more generic way to "Show in Explorer" option, otherwise, i do also request to add "Show in Explorer" by right click the editor's tab button, don't know if that possible. thanks.
(In reply to Yonggang Luo from comment #53) > sorry to disturb, i want to request add show file/folder function in > explorer at the Eclipse "Package Explorer" view, because some file is can > not be opened in Eclipse editor, This bug is about showing a file in an eclipse workspace in the filesystem explorer (Windows Explorer, Nautilus, etc). If you have a different request, please open a new bug. PW
