@dcyale said:

@dave r said:

@dcyale said:

I have never been happy with the native move tool for finessing pieces of a model together.

That's odd. I find it much quicker and more precise to use the native Move tool for placing parts.

I should mention (it was late when I posted the last) that I do almost all my work on a laptop with a touchpad. So no middle mouse button or scroll wheel, and less precision. Slows me down, but I can work when my kid is doing her sports practice.

I've found SU to be almost unusable via touchpad. My sympathy!

I posted one approach in this topic

http://sketchucation.com/forums/viewtopic.php?f=18&t=16015&start=90

[edit]
Hmm. for some reason that link goes to a topic doesn't exist page, despite the fact that I copied the URL from the page while I was viewing the posting...if you type it with http://sketchucation.com/forums prepended it ought to work?

It saves a separate image whenever you save a SketchUp file and causes Finder to use that Image for QuickLook. Not as neat as a technique that wouldn't require the separate image, but it works.

Steve

@cmac14 said:

Greetings,
I'm trying to import my Preferences.dat file from windows into my mac. Anyone know how?

The attached Ruby script should do the job (this is a plain script, not a plugin). WARNING this has been tested some, but could contain bugs! If it makes a mess, you can restore defaults in the SketchUp Preferences->Shortcuts panel.

Also please be aware that this loads your Windows shortcuts to Mac, it does not merge existing Mac shortcuts with the Windows shortcuts. That could presumably be done, but would require a more complicated Ruby.

To use this:

1. Export your shortcuts in Windows SketchUp via the Window->Preferences->Shortcuts panel. Click the Export... button, then on the export dialog that pops up, click Options..., check the Shortcuts box and uncheck the File Locations box (Windows file locations don't make sense on the Mac anyway). Click OK, then select a destination folder and click Export. This will generate a Preferences.dat file in the chosen folder. (The OP clearly already knows how to do this - I described it for the benefit of any other viewers who might not know).

2. Transfer the Preferences.dat file to your home Documents folder (I hard-wired this location)

3. Download the attached ruby to your Downloads folder

4. Run the ruby. You can do this using either a Terminal window or from within SketchUp.
   From a Terminal window type "ruby ~/Downloads/importprefs.rb" (without the quotes)
   From SketchUp, open the Ruby Console window and type 'load "~/Downloads/importprefs.rb"' (omit the single quotes, but include the double quotes). This will create a new file in your Documents folder named Shortcuts.plist

5. Quit from SketchUp (it must not be running when you do this step. SketchUp only reads the Shortcuts.plist as it starts, and overwrites it when it quits. If you copy the file while SU is running, it will be overwritten. That's one reason the script creates it in Documents). Then copy the Shortcuts.plist file from your Documents folder to your SketchUp folder. For SU 2013, this is
   ~/Library/Application Support/SketchUp 2013/SketchUp
   For older versions it is
   ~/Library/Application Support/Google SketchUp 8/SketchUp (or another digit if you are pre-8)

Note: your Library folder is hidden by default in Finder. To see it you can use the Go->Go to Folder menu item.

6. Restart SketchUp and your shortcuts should have been imported.

Let me know if you encounter issues.

Steve

importprefs.rb

After playing around with this a bit more, I may have answered my own question. On my Mavericks Mac, the skp:callback from TIG.remote fails with the now familiar error message if the call to allow_actions_from_host is omitted or invoked with a bad argument when the WebDialog is set up by Ruby (which is what Chris said before, I just didn't understand).

So, the concern isn't about executing an action on a remote host, it is about preventing skp: callbacks when the WebDialog contents were loaded from a remote host and might be malicious. Restricting the callbacks to pages from only trusted domains registered with this method then makes sense.

Which, of course, doesn't answer the question of why this method is ignored on most OS's and suddenly started working in Mavericks! But that will have to be answered by the Trimble SketchUp engineers, since the rest of us have no insight as to how this part of WebDialog is implemented.

As a note to the Trimble engineers: it would have been a lot easier for us outsiders to track this down if the error message was clearer. The message reports the full URL of the callback that it doesn't like (which is why we see the skp:callback@ part), and calls it an "Invalid URL" whereas it is actually a prohibited callback from a page that wasn't vetted by the Ruby code.

@chris fullmer said:

@slbaumgartner said:

OK, this just keeps getting weirder On my Mavericks Mac, TIG.remote works just fine after the typo is corrected. What the bleep is going on????

That is what we're seeing here as well Steve. From what we're seeing this all boils down to either having not included the allow_actions_from_host either not being implemented at all, or having been implemented with bad syntax (a url vs a domain string), or a typo.

It appears no other OS, other than Mavericks, actually pays any attention to this method. That is what my quick testing is showing. I'm very open to hear about exceptions to these findings or issues that might be different.

Chris

Whew, at least I might not be losing my mind

I read the documentation for this method multiple of times and I am not at all sure I understand it What sort of "actions" could take place on a "host remote from the host where the WebDialog exists"? That seems to say that an action callback could be routed to a remote host? How? The skp: protocol handler is part of the WebDialog code running on the local host...very confused...

@tig said:

Correcting the typo in the remote version does not change things anyway - the remote still fails with Mavericks... but the local version succeeds [with the unnecessary 'allow' method removed, on with the typo corrected or the typo intact]

BUT the weird thing is that if you try the [corrected OR typo-ed] tests on a pre-Maverick MAC or a PC, then both the local and remote versions perform just fine, as if the 'allow' and/or typo is ignored and the 'allow' is 'an irrelevance'

OK, this just keeps getting weirder On my Mavericks Mac, TIG.remote works just fine after the typo is corrected. What the bleep is going on????

@tig said:

It's already in the Devs' forum

faster than a speeding bullet...

For what it's worth, I just noticed that the same typo was present in both the TIG.remote and TIG.local methods, but only the TIG.remote failed due to the typo. Does allow_actions_from_host() look at previously loaded pages to see whether that host is used by any of them? How does the SketchThis ruby obtain the host URL it passes to this method?

@spottedrose said:

Hi, folks,

Has anyone else noticed SketchUp being ill-behaved after updating their Mac OS? SketchUp has occasionally crashed on me before, but now it's crashing regularly. I'm also having problems with copy-paste, or with clicks on a tool in the tools palette apparently not being seen, whether I use the stylus or the mouse (I usually use both at once). Any ideas?

=Fa

There have been a variety of issues reported, mainly with plugins. There is a topic about this in the Developers group.

@chris fullmer said:

Oh, TIG already responded. Yes, this is an odd one.

Chris,

It is easy to scan the WebDialog framework and confirm that this error message emerges from it, not from a Mavericks system library or framework. But without reverse engineering the WebDialog code (which for ethical reasons I won't attempt), it is impossible for us outsiders to know what WebDialog is trying to do when it throws this error. I have built and think that I understand the sample custom protocol handler that Apple provides, but it does not trap any issues with the URL. Without disclosing some proprietary info, would it be possible for the Trimble engineers to tell us what logic test fails when WebDialog throws this error? That info would help to track down what about Mavericks and certain URLs is peculiar to the problem.

As a different matter, it seems like this topic has gotten quite technical - maybe it should be moved or restarted in the Developers forum?

Thanks
Steve

@AdamB, were you getting the error message on the console, or just a blank page? I've noticed that when I open SketchThis, the content takes a very long time to load, with a blank page displaying until it completes. That would be consistent with what you say about WebKit startup being delayed. But after the WebDialog loads the page, if I click the import button I get the error on the console.

I'm having trouble reconciling the observations reported here, and I think there's a clue to be derived. The error message lists the entire URL, including the "skp:callback@" part. Normally, that prefix is stripped off by WebDialog and whatever follows @ is passed to the Ruby callback. Also, TIG has reported that his Ruby callback does not get invoked when this error occurs. None of us has been able to reproduce the error using simple test code.

The fact that the part after @ is an external URL should be completely irrelevant. To WebDialog it is just text. To reiterate: WebDialog has no business checking or accessing the linked website in these hrefs because it has no reason to assume that Ruby will even attempt to load the webpage in the text. The Ruby might parse the URL to extract other information, might save it for later reference, might use the URL text in another page it constructs... the possibilities other than loading the URL are endless. Likewise, to Mavericks, the part of the URL that matters is the skp: protocol prefix. It uses that to decide what protocol handler should receive the request, and leaves the processing of the URL details to that handler.

So, the problem has to be that for some reason we haven't yet figured out, WebDialog fails while trying to parse the request before handing it to Ruby.. The implication is that in Mavericks, the URL is somehow altered on the way to WebDialog in a way that WebDialog can't unravel. Maybe Mavericks doesn't separate the scheme and path parts correctly and this bombs WebDialog? To answer that, we need input from the Trimble team who know what causes WebDialog to generate this specific error and exactly what it receives from Mavericks vs from other OS's. Could this be a change in character encoding handling? Is something on the SketchThis page (e.g. javascript) altering the URL before it is passed on (so that what we see in the page source isn't what WebDialog actually receives)?

@driven said:

@tig said:

observation, if you just paste the address into Safari it downloads the file to 'Downloads', and you get a 'saved in v8' warning when you open that skp. Maybe the warning is blocking it being automated?

john

Nope - I am running 8 and get the same error there.

Steve

@tig said:

The only difference is my html has:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html>
BUT the SketchThis html source has:
<!DOCTYPE html> <!--[if IE 6]> <html id="ie6" lang="en-US"> <![endif]--> <!--[if IE 7]> <html id="ie7" lang="en-US"> <![endif]--> <!--[if IE 8]> <html id="ie8" lang="en-US"> <![endif]--> <!--[if !(IE 6) | !(IE 7) | !(IE 8) ]><!--> <html lang="en-US"> <!--<![endif]-->
I haven't managed to retest with that in my code, as I am currently downloading/installing Mavericks on that MAC...

I tried that DOCTYPE and conditional stuff. No effect - my test code still gets the right URL. The Jquery stuff is way more complex than I feel competent to fiddle with...haven't used it enough.

@tig said:

I too have written some simple href="skp:callbackname@string" examples, which I thought might break Mavericks.
They didn't.
Then I rewrote the SketchThis code so that it puts into the Ruby Console the string that is received from the 'install' click href=... callback.
Surprisingly it never gets to this point, instead it just presents the "Runtime error: invalid URL 'skp.callbackname@http_url_path.skp'", then stops - never displaying the string as it never gets a valid callback returned.
This is plain weird...

So, WebDialog is throwing this exception before it ever passes the callback to your Ruby. The Foundation library must have identified the skp: "scheme" correctly, else it would never have handed this request to the WebDialog's protocol handler. But for some reason either it or WebDialog is failing to extract the correct path out of the request. I remain baffled why we can't reproduce this in simple test cases. That's especially frustrating because if we can't identify a causing pattern, we can't recommend a viable workaround.

Pulling at any thread I can find: this page makes use of jQuery to do things such as track usage. Could this be somehow entangled? Just as a theory, could Mavericks have changed something in the javascript engine that causes this bug and we aren't reproducing it because we aren't firing the same javascript enroute to Ruby? Seems like a long shot, but when in desperation...

@tig said:

But my own test-rb+html , the SketchUcation Plugin Store AND SketchThis all use set_url()
Only SketchThis fails with Mavericks.
It uses:
href="skp:callbackname@http://url.skp"
Which was the initial 'suspect', since the SketchUcation Plugin Store is reported as working OK and that uses onClick and js function with the equivalent of:
window.location="skp:callbackname@http://url.skp"

However my tests include various permutations of 'clicking' to callback - i.e. href=... and window.location=... etc - and ALL of those work on Mavericks, and return the passed string correctly, whereas the very similar looking html code href=... for SketchThis fails with the 'invalid URL' message in the Ruby Console ???

Weird indeed!

Our attempts at test cases don't produce the error, so we must be overlooking something subtle about the exact way that the SketchThis page is constructed. I tried the exact URL from their page in my callback test, and it worked fine. So it isn't the address. It has to be something about how it is set up on that page. But what???

@slbaumgartner said:

@ericschimel said:

And here's a screenshot of the ruby console error from my plugin:

http://note.io/1a5H9F5

And here's a screenshot of the same error in Keyframe animation:

http://note.io/1gNdwlo

Again, if there is anything I can do to help out, please let me know.

Aha, that's the difference! The prior info didn't lead me to understand that the error is on "Insert into model". When I do that, I get the same error. Unfortunately, since the plugin is scrambled ruby I can't actually debug it.

Mavericks includes a new version of the WebKit library (I just checked), so they must have changed/broken something that impacts the way that the skp: protocol is spliced in.

There must be something more going on in this Tool than I am privy to. I wrote a little test ruby and html page that uses <a href=skp:callback...> to generate a callback to Ruby, and I get the parameter string as usual, without error, including when it is the exact URL in your page. I do not get the skp:callback@http://... stuff reported by the error message. Also, I found that error message string in the WebDialog code, so I think it is thrown back at Ruby from WebDialog when the Ruby code does something to try to load the skp into the model.

TIG, I think this is back in your court, since the Ruby is scrambled.

@ericschimel said:

And here's a screenshot of the ruby console error from my plugin:

http://note.io/1a5H9F5

And here's a screenshot of the same error in Keyframe animation:

http://note.io/1gNdwlo

Again, if there is anything I can do to help out, please let me know.

Aha, that's the difference! The prior info didn't lead me to understand that the error is on "Insert into model". When I do that, I get the same error. Unfortunately, since the plugin is scrambled ruby I can't actually debug it.

Mavericks includes a new version of the WebKit library (I just checked), so they must have changed/broken something that impacts the way that the skp: protocol is spliced in.

@tig said:

The first report I got was yesterday: it is from the SketchThis toolset and site-page component_load tool...

I just installed the SketchThis toolset and clicked their tool links. They are sometimes very slow (looks like a blank page), but I got to their site. Have they already rewritten this?

@tig said:

The first report I got was yesterday: it is from the SketchThis toolset and site-page component_load tool...
Their HTML guy compiles the server-side's possible skp download lists into HTML coded buttons using: <a href="skp:callbackname@http_url_path_to_skp" ... etc
On the Ruby-side the callback is fired and it receives the url string to the right of the @.
This works fine using PC and MAC.
It fails with Mavericks - the passed string after the @ seems to be replaced with the whole callback string including the 'skp:callbackname@' part, so the url is then invalid.

I have asked them to look at changing to a simple header defined js function
function callbackname(url){ window.location='skp:callbackname@'+url }
that is in turn the called in the linked buttons instead of hrfe=... as
onClick="callbackname('http_url_path_to_skp');"

It will continue to work in PC/MAC and hopefully in Mavericks too...
I am at a loss to see what Maverick's Safari is doing differently

Because the Plugin Store's web-dialog uses similar 'onClick=' callbacks [rather than the 'href=' way], then I'd like some feedback from Mavericks users - specifically that the AutoInstall download/install works as expected, and the 'More Info' button link also opens OK - this will show that the callbacks are still getting the correct url passed to them...

Both Autoinstall and 'more info' worked fine for me.

I've always used the window.location=... technique, not href. I'll look around to see if I can find another example (or contrive one). Do you suppose it is related to link directly from HTML vs window.location setting from javascript? It doesn't make sense to me that this difference would change the way the skp: protocol processes its arguments, but...