Posts made by slbaumgartner

@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...

@tig said:

What I have just seen reported is that at least in some tools' server-side callbacks, it passes the whole callback command-string as if it were the string-part [after the @] - e.g. the SketchUp callback ' callbackname' is correctly called, BUT it is passed the id & skp:callbackname@http_urlstring_to_load_skp instead of the usual id & http_urlstring_to_load_skp.
Running the callback on PCs or older MACs works fine, but with Mavericks there will be a Ruby Console error that the URL is invalid [and of course it is invalid as a url when it's prefixed with " skp:callbackname@"]

The web-dialogs should still load just fine, but it's the callback part etc that fails when the callback's string gets 'mangled' - breaking linked downloads, linked page opening etc. If any of you test this please do so with the Ruby Console open and post any error messages [or successes!]

Didn't hit this in any of the tools I normally use. Can you identify specific offenders?

Just tried both SU 8 and SU 2013 on Mavericks, and they both launch and open files just fine. Of course, it will take some use to be 100% sure that everything works, but I don't think Apple changed anything that should matter to SU.

These texts were almost surely drawn using the view.draw_text method. So far as I know, there is no setting exposed in SU that controls the font or size used by this method. Alas, I think this method has not been adapted for retina and sets the text size in physical pixels instead of screen points. Depending on whether the text is also tiny on a Windows box, I suppose this could be considered a bug.

What size retina do you have, and what screen resolution setting are you using? On my 15.4" MBP retina using the default "best for retina" resolution, the text is tiny but legible. On the 13.3" it would be still smaller. If you have set a resolution that is not an integer multiple of the physical pixel counts, that could make this tiny text blurry as well.

If you have two points p1 = [x1,y1,z1] and p2 = [x2,y2,z2] the line passing through them is given by

[x,y,z] = p1 + k(p2-p1)

The segment of the line between the two points is for 0.0 <=k <= 1.0

So, if intersect_line_line returns a point (meaning that your two lines intersected), you just have to test that the intersection point satisfies the equation above for a k in the allowed range. It will necessarily be the same k for x, y, and z.

@glitchdesign said:

Hi,
I found this thread because i have the QL helper issue too. I've tried the ql manage steps listed above. I can't say for sure if .skp is the only thing that makes ql go nuts, but there's no doubt that it is a trigger. I've never come across anything like the quicklook generator posted above, will it help specifically with this problem, or is it more just for being able to view files before opening them? Where should i put the .qlgenerator file? I'm afraid i'm not too experienced with this stuff...

So far as I know, nobody ever conclusively proved the cause of this problem, so there is no guarantee of what will work. My theory was that it could be due to SketchUp not registering the .skp extension correctly with Mac OS X, which would cause Finder's preview to scan the file trying to decide how to display it and could clog up the quick look cache. I am sure that SU 8 did not register .skp, but I haven't checked on 2013.

Unzip the qlgenerator into ~/Library/QuickLook and the ruby into your plugins folder (the path varies depending on SU version). You may have to run "qlmanage -r" from a console window before the quick look daemon will pick up the new generator. You also have to save a file once before you will get a preview image instead of the sketchup logo.