Add open containing folder and open in tab actions.

[mbien]

like open-in-system but opens the parent + open-in-tab actions

extracted AbstractOpenInAction as common superclass for

• (old) OpenInSystemAction
• (new) OpenParentInSystemAction
• (new) Open(Parent)InTabAction

(the expertly drawn red line marks a cut in the screenshot since the menu is longer)

[mbien]

removed milestone

[Chris2011]

As the title says "open containing folder" this is my suggestion to add it like this.

[mbien]

I originally had this in mind but I am still trying to find a place for another action: "Open Folder in NetBeans"

To deconflict this we would have to call it "Open Containing Folder in System" which is quite long. So I picked "Open Parent in System" which is concise and still manages to describe exactly what it does.

The other option is to use sub-menus, the problem there is that this would be 3 layers in some situations, which I would like to avoid if possible.

[Chris2011]

Open Folder in NetBeans could also called "Open Folder as Project" or smth like that. It has a different context, but I'm fine with it then.

[mbien]

Open Folder in NetBeans (which can also open jars, who knows what else it can open) would not be the same as open project

[Chris2011]

I know I already implemented this as a 3rd party plugin, but to make it clear I call it "Open Folder as Project". Because it will be shown in the project tabs. It has not all functions that a project has, but this makes it more clear IMHO. I know via CLI you can open Folder in NetBeans, which will open a folder within a new TopComponent. Is this what you mean and want to do?

Anyway, it is out of scope for this ticket and we can discuss the other stuff in another PR or via discussion. At the end, I'm fine with it, the wording in some cases in NetBeans is in my opinion not often as clear as I already told it but it is better than nothing.

[mbien]

refreshed this PR as POC.

Its now 4 actions. This is too much for the context menus atm (esp for the project menu), so we would have to identify items which belong together and move them around a bit if we want to expand the functionality.

[mbien]

rebasing to get a devbuild since i forgot how this worked

edit: added screenshot

[neilcsmith-net]

I can see some benefit to rationalizing here, but the code as-is wouldn't allow replacement of the existing macOS Show in Finder action. That needs Desktop.Action.BROWSE_FILE_DIR. It might be nice to replicate that behaviour elsewhere, although it's possibly a bit hacky - a shame the JDK hasn't implemented it.

I'm not sure what the object of the Open in Tabs action is? I have a feeling it might be better implemented in a different way, but I'm trying to understand the workflow where you want to use this?

[mbien]

replacement of the existing macOS Show in Finder action.

I don't really know what the special case is. OSes maintain a set of default applications for file types and paths. Opening a path on cinnamon will open it with nemo (which is a fork of nautilus), on windows it will open the file explorer - I assumed it would open the finder on mac? (my last mac was a while ago, I don't remember those details anymore)

The main difference is in the open vs browse action, e.g should html be opened in a system text editor or the browser. So I don't know the difference between desktop.open("/tmp") and $ finder /tmp - i always assumed it would have the same result.

What OSes can also do is to open files in file browsers and pre-select them on open. Both impls don't do that atm as far as i see. ($ nemo /tmp/foo.txt). Is this the aspect what is wanted on mac?

I can add an if (mac) {open it slightly differently} but I don't know what that would be.

I'm not sure what the object of the Open in Tabs action is?

it is currently only exposed indirectly via drop to editor (and CLI). It even works with jars or other things which can be opened. The open-project window doesn't let you to that either.

I found that to be useful to open an extra folder for a few tasks, but getting there always needed extra steps. (open parent folder than drag to editor). Students might find that useful too if they have to work with compact-java files or similar things. I discovered it accidentally while starting NB via script and setting some paths.

edit: this is also a super classic NB feature since long ago NB required to mount things you wanted to see in the IDE

[neilcsmith-net]

The main difference is in the open vs browse action, e.g should html be opened in a system text editor or the browser. So I don't know the difference between desktop.open("/tmp") and $ finder /tmp - i always assumed it would have the same result.

What OSes can also do is to open files in file browsers and pre-select them on open. Both impls don't do that atm as far as i see. ($ nemo /tmp/foo.txt). Is this the aspect what is wanted on mac?

The existing macOS action, and my replacement, do exactly this. This is not browse vs open. It defaults to Desktop::browseFileDirectory and only uses open as a fallback.

Ideally this would select in system across all OS. I chose Locate in System over Select in System because this is not currently the case. I'm curious if any Linux dists have bothered to implement this action - I'm assuming not. Yes, we could potentially offer fallbacks other than Desktop::open.

I can add an if (mac) {open it slightly differently} but I don't know what that would be.

As in #9246 and above, and with no macOS check.

it is currently only exposed indirectly via drop to editor (and CLI). It even works with jars or other things which can be opened. The open-project window doesn't let you to that either.

Yes, it's useful. You can also use Open File with archives. I don't think this is the correct place to put or implement this. And it's a shame the opened tabs aren't persistent. Ideally we add an option to use the existing open support on folders and archives. Better behaviour may even belong in the Favorites module.

[mbien]

I'm curious if any Linux dists have bothered to implement this action - I'm assuming not

$ nemo /tmp/foo.txt will open /tmp/ and select foo.txt within that window. JDK doesn't implement it on my system. But at least I know now what the finder issue is all about.

OPEN supported: true
EDIT supported: false
PRINT supported: false
MAIL supported: true
BROWSE supported: true
APP_EVENT_FOREGROUND supported: false
APP_EVENT_HIDDEN supported: false
APP_EVENT_REOPENED supported: false
APP_EVENT_SCREEN_SLEEP supported: false
APP_EVENT_SYSTEM_SLEEP supported: false
APP_EVENT_USER_SESSION supported: false
APP_ABOUT supported: false
APP_PREFERENCES supported: false
APP_OPEN_FILE supported: false
APP_PRINT_FILE supported: false
APP_OPEN_URI supported: false
APP_QUIT_HANDLER supported: false
APP_QUIT_STRATEGY supported: false
APP_SUDDEN_TERMINATION supported: false
APP_REQUEST_FOREGROUND supported: false
APP_HELP_VIEWER supported: false
APP_MENU_BAR supported: false
BROWSE_FILE_DIR supported: false
MOVE_TO_TRASH supported: false

But I haven't tested on more mainstream linux distros like ubuntu yet.

I don't think this is the correct place to put or implement this.

plus

Better behaviour may even belong in the Favorites module.

Well the nice thing about it is that it is in the Favorites context menu too. I think it fits well into the category of open actions, one opens the path using a OS tool, the other using NB. I wouldn't bother to navigate to a folder first via project open just to open it in a view. Open parent folder in system + drag would be still faster even though it feels like a hack.

[mbien]

renamed "Open Parent in System" to "Locate in System" + the action will now use browseFileDirectory(selected) if available and open(selected.parent()) if not. If I understood this correctly, this would select the file in finder on mac which was the missing functionality.

[neilcsmith-net]

If you want to pursue this change here instead, then please include the removal of the macOS action and the new shortcut.

These actions might need to work with a set of FileObject instead of File. I've just realised something I'd missed in the finder action - it tests if the file is in an archive and opens the location of the archive file instead. That needs to be replicated too.

But I haven't tested on more mainstream linux distros like ubuntu yet.

Not that I can tell from testing this already. And it doesn't look like it's in the Wayland support either. Calling an external process might be the only way to achieve this. Workarounds listed elsewhere include explorer.exe /SELECT for Windows. On Linux, there doesn't seem to be anything in xdg-tools that will do this. Which leaves maybe dbus.

I think it fits well into the category of open actions, one opens the path using a OS tool, the other using NB.

I'm partly concerned about bypassing the existing open support, and I also think that it makes sense for folders and archives to have an Open in New Tab at the top of the menu similar to other files, and project folders. I realise that is slightly different to what you're proposing, just think it's more obvious what it is and where to find it.

Can we split the two changes for now?

[neilcsmith-net]

Further to the dbus option, this sort of external call seems to work, but might be more trouble than it's worth! 😄 Would still need open as a backup.

gdbus call --session \
  --dest org.freedesktop.FileManager1 \
  --object-path /org/freedesktop/FileManager1 \
  --method org.freedesktop.FileManager1.ShowItems \
  "['file:///home/username/Documents']" ""

[mbien]

If you want to pursue this change here instead, then please include the removal of the macOS action and the new shortcut.

sure

I've just realised something I'd missed in the finder action - it tests if the file is in an archive and opens the location of the archive file instead. That needs to be replicated too.

will take a look at archive paths - haven't really considered those so far.

update: none of the actions are active for archive paths:

("Open in Terminal" will fail btw)

so far we had the following other feature requests:

• UI persistence for opened views (should it integrate with project groups?)
• select-in-explorer functionality for more systems
• open-folder-as-tab via open project window

i think those would build on top of this functionality and don't really have to be addressed all at once. The "new" actions (they aren't really new just consolidated into one menu) would already be useful without those follow ups IMO.

[neilcsmith-net]

update: none of the actions are active for archive paths:

Mine is, it just doesn't work properly! 😄 That's what I mean about working with FileObject rather than File. I just missed the lines at https://github.com/apache/netbeans/blob/master/platform/applemenu/src/org/netbeans/modules/applemenu/ShowInFinder.java#L73

i think those would build on top of this functionality and don't really have to be addressed all at once.

Agreed! We're coming at the same things from different angles here. I was looking to address the need to remove the reflection usage in applemenu while not losing any functionality there (or having an almost duplicate action to hide).

[mbien]

note to self: try to remove --add-exports=java.desktop/com.apple.eio=ALL-UNNAMED