UI.openURL( local_path ) doesn't work on Mac OSX

Hello,

openUrl() shows a local path on Windows Explorer
UI.openURL(“C:/Users/SUalive4u/SketchUp/anim SUalive/saw_CE/”)

but the following doesn’t work on Mac OSX
UI.openURL(“/Users/iMac56-J/”)

How making it at work?

Regards

I think that is because on Mac OS that is not a correctly formed URL. You need to prepend it with “file://”

For cross-platform compatibility your can pre-pend to the passed file path:
SO… MAC’s
path = "Users/iMac56-J/"
OR… PC’s
path = "C:/Users/SUalive4u/SketchUp/anim SUalive/saw_CE/"
BECOMES
UI.openURL("file:///#{path}")

Hello,

Weakness of our Ms culture where file protocol can be omitted!

Thanks for your answers.
Both work but TIG’s syntax does not go through our “code compiler”. I added the third forward slash as it is said aiming local url.

have a good weekend

UI.openURL has been changed in 2019.3. SketchUp does note URL code it anymore on Mac.
I think it affects this coding.
Having problem.

Mario, could you say more about the problem you encountered? I’m not clear how the issue discussed in this topic would be affected. According to the Ruby API documentation, the change in SU 2019.3 on Mac is that this method no longer encodes the argument - for example, the space character is not replaced by its encoded form %20. That’s different from whether or not a correct URL requires a full protocol specification such as ‘file://’.

This appears to be a cross platform solution to opening files.

Hi Steve and Christina,
In this case the aimed file is a PDF.>

help=Sketchup.find_support_file([‘Help.pdf’,File.dirname(FILE))
if Sketchup.platform =~ /osx/
help=“file://” + help
else help=“file:///” + help
end
UI.openURL(help)

Nothing happens, so it must not find it. Encoding ? or path ?
Tried with every number of forward slashes from 0 to 4.

Made another try in ruby console.

help=Sketchup.find_support_file(‘Help.pdf’,File.dirname(FILE))
UI.openURL(help)

gave me a Mac error -50, The application can’t be opened
So I guess it did find the file this time.
But Catalina restriction? Could it be that the embedded browser does not have permission?

I assume these samples were extracted from a larger code, as for example FILE is an undefined constant. Did you mean FILE? Edit: Oops, the forum software obliterates the double underscores on that, which is probably what also happened to your posted code snippet.

As posted, the samples use smart quotes, which won’t parse correctly. I assume that’s something the forum software did? You should use triple backticks to preserve your code from markdown interpretation on the forum.

The [ before ‘Help.pdf’ is a syntax error typo.

You should test for a nil return from find_support_file to see whether it succeeded.

The second example won’t work for lack of the “file://” protocol specifier, as discussed earlier in this topic. When I try a file without the file://, I also get error -50. But when I include it, the pdf opens. The error is telling you that the system doesn’t know how to open a URL with no protocol specified. SketchUp.find_support_file does not add the protocol since it does not know you mean to use the file path as a URL. Also, unless you are sure it is “clean”, you must URL encode the value before passing it to openURL. For example, spaces are illegal and must be escaped with %20 or +

Ok, added the file protocol, got rid of error -50.
(the others; typo, missing underscore and smart quotes were not really in my code)
Path is ok, not nil. But code returns false. Tried with 2 and 3 slashes (as above).

helpfile=Sketchup.find_support_file(‘Help.pdf’,File.dirname( _ FILE_))
help=‘file:///’+helpfile
UI.openURL(help)

Thanks a lot Steve, the good thing is now I know that it is not due to the change in the API.
p.s: your right the forum software alters the text, badly, when formatted to code like.

Try puts the various values you build for help before calling UI.openURL(help) and tell us what you see in the Ruby console.

The forum uses Markdown syntax, in which, like HTML certain symbols are special and get reformatted. If you put a triple-backtick on the line before the code and on the line after the code, it will display verbatim what you typed. Better still, if you put ```ruby on the line before and triple backtick on the line after it will format and color code the Ruby syntax:

helpfile=Sketchup.find_support_file('Help.pdf', File.dirname(__FILE__))
help='file:///'+helpfile
UI.openURL(help)

Great, I finally saw that the path had a space in it (folder Application Support).
So due to the change in API, I recommend adding at least one line of code:

file.gsub!(' ', '%20')

That did it.

That should also be backward compatible with older versions.

on a mac, for mac’s I just use %[open “#{ xxx.pdf}”] and let system open it in Preview or whatever the user default is for the filetype…

john

2 Likes

Some notes,

Avoid Sketchup.find_support_file as it only works with extensions installed in the standard plugin folders. Absolute are safer as users may very well install their extensions elsewhere.

Also their is an encoding error in __FILE__ on Windows that you need to account for if the path contains non-ascii characters (often the user folder of an Asian user). This is commonly done already in the registrar file just ones, and then a constant holding the plugin’s root directory can be re-used throughout the plugin.

This is how I write my registrars: Viewport-Resizer-2/ene_viewport_resizer2.rb at master · Eneroth3/Viewport-Resizer-2 · GitHub

I’d recommend using Ruby’s methods to properly encoding URIs to make your code more robust. You never know when you suddenly have other characters than spaces.

Reading this thread it sounds like the SU2019.3 bugfix to UI.openURL had some additional side effects.

The reason we changed it was because it was not possible to open URLs with anchors (including #). Other important characters would also be encoded making it impossible to some open valid URLs.
This was happening because the macOS version of SketchUp URI encoded the whole string.

The Windows version of this never URI encoded the string so we decided to make it consistent on both platforms. This means on both platforms you need to provide a proper URI encoded string.

We did expect there might be some extensions breaking because of that, but thought it might be limited since Windows required URL encoding (and it’s the largest user share so most extensions are well tested against that platform.)

However, it appear that many use it to open local files, something we didn’t really test. The API contract for this method as simply been to open the browser with the given URL.

That being said, it sounds like we can improve the documentation for this method to provide references to the Ruby StdLib utilities that can be used to URI encode the strings.

We can also provide examples of how to open local files across both platforms. (Sounds like prefixing file:/// is the cross-platform way to do so. Something maybe IE does automatically and WebKit doesn’t do - but our previous URI encoding did.)

Though, I would have preferred to add a new method that explicitly supported what people are wrangling UI.openURL to do.

1 Like

I logged an issue to improve the documentation and examples for UI.openURL:

1 Like

+1 for a UI.open or open_file method.

1 Like

Presumably open using the default app for the file type? Would need good error handling for types with no registered handler.

1 Like

I think the OS typically show up a prompt asking you what program to use. If I’m not mistaken this w´should not be SketchUp’s or the extension’s responsibility to handle.