OpenInSystemAppOperation

[kirkilj]

I'm not in a position to test this myself at the moment, but I stumbled upon an Oxygen Operation that I must have missed before.

Does the OpenInSystemAppOperation operation allow us to launch a shell script or Windows batch file?

Here’s the definition from the Author SDK:

@API(type=INTERNAL,src=PUBLIC)
public class OpenInSystemAppOperation extends java.lang.Object implements AuthorOperation

Function: Detects the application that is associated with the given file in the OS and uses it to open the file.

Here’s what it looks like in the Framework Action configuration in the Oxygen UI:



In addition to launching shell scripts, I'm assuming this could also be used to open an SVG in Inkscape if that’s what the user has configured for the filetype in their OS. If I’m reading the docs correctly, no custom Java is necessary in order to implement this capability.

John

[Radu]

Hi John,

The OpenInSystemAppOperation operation is useful to instruct the application to open a certain resource in the associated application.
For example for DITA you can edit the DITA document type and look at the play.media action used to open in an external application the value referenced by the <object data="..."...> attribute.

So the operation is not useful to run a certain command line or script. But this is a good idea and I will add as an improvement request the possibility to create a special ExecuteCommandLineOperation. In the meantime you would need to create your own custom AuthorOperation implementation which would use Java code to start a certain process.

About this remark:

In addition to launching shell scripts, I'm assuming this could also be used to open an SVG in Inkscape if that’s what the user has configured for the filetype in their OS. If I’m reading the docs correctly, no custom Java is necessary in order to implement this capability.

Yes, the OpenInSystemAppOperation can potentially be used for this.

By default when double clicking an SVG image, it is opened in Oxygen and then in the opened SVG editor you can use the "Open in Browser/System Application" button to open it in the associated system editor. Maybe we should change this behavior, when double clicking an SVG image in the Author mode just open it in the system application. The issue with SVG is that it is both XML and an image but probably there are slim chances that somebody would actually edit the SVG using Oxygen. I will add an issue for this as well.

Regards,
Radu

[kirkilj]

I want to check in and see if the functionality discussed in the topic is still in the queue for consideration.

Associating Inkscape as the preferred SVG editor in Linux has been problematic thus far for me.

My ugly work-around was to create a couple External Tool launchers for Inkscape, (1) for opening the SVG that is open in the Oxygen XML editor (in all its glory) in Inkscape and (2) launching Inkscape with no parameters.

[kirkilj]

Also, can I safely assume that the Open file at Caret function (Ctrl-Enter) does the same thing as the Open in System Application Button if the caret is within a reference to an SVG file?

[Radu]

Hi John,

What version of Linux are you using?
I made some tests with Ubuntu.
In Ubuntu for example to associate a file with a certain editor you right click it, go to Properties->Open With and choose the editor to use for all similar extensions. Afterwards, this works when double clicking the file in the native System Browser but it will still not work when double clicking it in Oxygen which will still open the default image viewer.

We call the only API that we have available in order to use the associated application for it, but it seems that this is a bug in Java which has not yet been fixed:

http://bugs.java.com/bugdatabase/view_b ... id=6799791

But a workaround which worked for me in Ubuntu was that after I double clicked in Oxygen and the default image viewer/editor was launched, in that default editor I opened the File menu and it had an "Open With" submenu from which I launched Inkscape.

Regards,
Radu

[kirkilj]

We use RedHat Enterprise Linux.

The current, less than elegant, workaround is to ask the user to open the svg in the XML Editor, and then invoke an External Tool that I created to specifically references the Inkscape executable on our network so that we don't have to worry how each user has their Linux file associations set up. We're also going to write Python scripts to extend Inkscape, so it's important that a specific executable of Inkscape be launched from Oxygen.





Ideally, it would be great if the File Types preferences allowed a user to specify that a specific external application should be launched when attempts are made to open the specific file type from Oxygen.

Perhaps something similar to:



and



and maybe an additional option for the system default application for Windows and Mac users who aren't using a centrally managed set of applications on a virtualized server farm. We have other tools, such as custom timing diagram editors that may require a similar facility.

Other than asking users to create a "shadow" Oxygen project with a reference to a directory, is there a reason why there's not a file explorer view or file-system data source explorer connection built in to Oxygen so the user doesn't have to switch contexts to view their content and drag-and-drop references to image files all from within Oxygen? There are plenty of useful explorers for other container types (e.g. archives, CMSs, etc.) I know that drag and drop is supported from file-system explorers outside of Oxygen, which is definitely a step forward, but not where'd we like to be, because many of our Linux users don't use a window manager from which to drag and drop their SVG files into Oxygen.

Apologies if I'm overwhelming you with an abundance of wishes, but they're all trying to solve the problem of integrating Oxygen more smoothly into our workflow, in this case with SVG images so we can ease the transition from Framemaker for our users. To the degree that users can camp-out in Oxygen as the hub of their documentation work, the better off we'll be.

Thanks for all the great work you're doing.

Regards.

[kirkilj]

I just discovered something else that I could use your help on.

If I create the following debugging external tool in which the command line is:

Code: Select all

echo ${env(PWD)}

and the Working directory is the default "."

It echos the Oxygen installation directory instead in the output view where it appears that the Editor variables are being overridden by the installation directory /scratch/b20755/oxy3.

Code: Select all

Started: echo /scratch/b20755/oxy3

/scratch/b20755/oxy3

Process ended with exit code: 0

It does the same if I use the Editor Variables to set the Working directory to ${homeDir} or ${cfd}.

If I try to prepend an explicit cd in the field:

Code: Select all

cd ${cfd}; env(PWD)}

, it just fails as I've learned separately on an earlier support request.

Clues?

[kirkilj]

I forgot to mention in the previous comment that I was echoing the current directory as well as other directories to figure out why Inkscape's working directory wasn't correct either, so I eliminated Inkscape and used a basic echo instead for debugging purposes.

[Radu]

Hi John,

Pleas see some answers below (and tell me if I missed any question):

Ideally, it would be great if the File Types preferences allowed a user to specify that a specific external application should be launched when attempts are made to open the specific file type from Oxygen.

I will add an improvement request for it. One other thing you could to would be to create your own Author Operation which launches Inkspace and mount it on the contextual menu. The Java operation would look at the current node and if it is an image, take its @href attribute value, combine it with the location of the current file to create an absolute file and launch an external process.

Other than asking users to create a "shadow" Oxygen project with a reference to a directory, is there a reason why there's not a file explorer view or file-system data source explorer connection built in to Oxygen so the user doesn't have to switch contexts to view their content and drag-and-drop references to image files all from within Oxygen? There are plenty of useful explorers for other container types (e.g. archives, CMSs, etc.) I know that drag and drop is supported from file-system explorers outside of Oxygen, which is definitely a step forward, but not where'd we like to be, because many of our Linux users don't use a window manager from which to drag and drop their SVG files into Oxygen.

I understand, I will add this as an improvement request. As a workaround you can add in your project a reference to the "/home" folder or to any other folders you want.
Or you could create a plugin with a custom view which embeds a file chooser.


Now with regard to your editor variables expansion experiments:

${env(PWD)} prints the Oxygen installation directory.

I consider this normal behavior, whenever an application is started, the working directory environmental variable is consider to be the place where the application started.
So ${env(PWD) is always expanded by our code to the started Oxygen's working directory.

http://en.wikipedia.org/wiki/Working_directory

We use the available API to read this environmental variable and this is the value which we obtain through this API.

You mentioned:

It does the same if I use the Editor Variables to set the Working directory to ${homeDir} or ${cfd}.

I do not quite understand what your intentions are. Do you start a command line which also tries to set an environmental variable to a certain value? How does it look like?

When you create an external tool in Oxygen it already has a "Working Directory" field which can be set to ${cfd}.
Instead of calling cd ... the external tool could call a script which receives certain parameters from Oxygen and works with them.

Regards,
Radu

[kirkilj]

Thanks for the reply.

I think I understand now. The ${env(PWD)} is an Oxygen variable that is evaluated by Oxygen before the command is sent to the OS. So if I use

Code: Select all

echo $PWD

instead as the command string, then Oxygen will pass the "$PWD" as an unevaluated literal string to the subprocess or subshell where it will be evaluated by the OS after the working directory has been set.

I got Oxygen's evaluation of the PWD environment variable before the external tool was invoked confused with the OS's evaluation of $PWD once the forked process or sub shell was executing.

Apologies

[Radu]

Hi John,

You understood perfectly.

Oxygen takes the string you are composing and replaces all editor variables it recognizes in it with their values (this happens in Oxygen's own process).
Then it starts/forks a new process from the Java code to which it gives the modified string to execute.

Regards,
Radu

[sorin_carbunaru]

Hello,

I am glad to announce that the newly released oXygen 18.1 comes with a default Author operation called ExecuteCommandLineOperation, that can be used to run command lines. More information about the operation can be found at: https://www.oxygenxml.com/doc/versions/ ... tions.html.

All the best wishes,
Sorin Carbunaru
oXygen XML