'Open OPI in View' opens view even when given an nonexistent absolute file path

[mfurseman]

To reproduce:

Create a widget on an OPI, and add the action 'Open OPI in View'. Specify an absolute file path that doesn't exist. When run the view is opened, then an error is shown, leaving an empty OPI View.

This doesn't happen with relative file paths.

I have a patch that can fix this issue, should I make a pull request?

[berryma4]

Maybe related to #644

[willrogers]

This patch doesn't work. If the 'absolute path' is relative to a workspace, it begins with a slash but is not a filesystem location. The check prevents valid workspace locations from being opened.

Branch bug648v2 handles both cases.

[berryma4]

Now that you mention it, what about URLs?

[kasemir]

Note that "Open in View" should be removed for Eclipse 4 anyway. The reason for "Open In View" was that you can detach views. In Eclipse 4, you can detach anything.

Unclear if the Editor or the View will remain, but only one of them should.
Maybe the View because it is part of the "Perspective", so we can save/switch/lock *.opi setups that way.
Or maybe the Editor because it has an input. .. But that really only matters for editing, when the 'dirty' state needs to be tracked.

[kasemir]

Going back to "opens view even when given an nonexistent .. path", I think this is actually desired behavior, no matter if the path is local, remove, relative or absolute.

My current leaning for CSS 4.x to have all OPI runtimes use a "View", so "Open In View" is the same as just "Open". This is currently on the "boy_runtime_view" branch.
If the path to open doesn't exist, the OPIView will still be there, with an error message in it:

When one opens a new display, this is typically done via a button that used to point to an existing file. Or CSS is restarted, and on restart it tries to restore the displays as they were before the restart.
If the file to display vanished, maybe because it was behind an http:// link that's intermittent, or the file was removed, it's OK to restore the original view but with the error message inside. User can then take note of the missing file and close the view. Especially when several display panel are restored, and they are all missing their input file, it's better to have them all show up with an error indicator inside, than having to go through N popup-dialogs that all need to be acknowledged.

[willrogers]

Right - I guess that might make sense for views.

We can override this behaviour for our EDM windows.

[kasemir]

Well, imagine you "restart", and it's restoring 10 of your "EDM" windows,
but due to a file access problem they cannot be populated.
What do you prefer:
a) Those windows show up in their original location, containing an error
message "Error loading display /volumes/common/displays/a/b/c/*.opi". User
can create a screenshot and send that to the control system group, then
close the windows.
b) Don't restore the parts. Instead, user gets one dialog "Error loading
display /volumes/common/displays/a/b/c/one.opi", closes that, then another
dialog "Error loading display /volumes/common/displays/a/b/c/two.opi" and
so on. User eventually closes them all, but forgot to write down which
displays were missing.

When Eclipse restores an "editor" with missing input, that tends to create
no dialog. Editor appears as usual, but with error message in content. I
think that was a good design.