SketchUp and OSX Mavericks....

ericschimel

So some of that was over my head, but if it helps at all, there are other plugins that are failing in the same way as well, try KeyFrame animation and attempt to start a trial by using their web dialog, it also fails...

TIG

I have at least managed to 'crowbar' Mavericks into my MAC !
I can confirm that the test code Eric posted earlier works for TIG.local and TIG.remote on all PCs and pre-Mavericks MACs. However it fails miserably on Mavericks with TIG.remote and href=

AdamB

I had a look at this yesterday for LightUp when I started getting reports of blank dialog windows on Macs running OSX 10.9 on Friday.

I believe most of these posts in this thread are way off the mark. I may be wrong, but I believe its nothing to do with WebDialogs looking at text strings after @ etc. I believe it is Mavericks using increasingly fine grain parallelism and in particular being much less speculative in launching CPU - and therefore power consuming tasks - which is after all the USP of 10.9.

So LightUp now runs fine on Mavericks and I posted new builds and installer (v3.0j) yesterday.

It now works on Mavericks because I procrastinate communicating with WebKit until the latest I can to ensure it really is running. Using set_file etc before this appears to simply be talking into an azure blue void.

Adam

AdamB

Should say I posted new builds of LightUp Analytics for Macintosh too.

LightUp updates for OSX Mavericks available here: http://light-up.co.uk

LightUp Analytics updates for OSX Mavericks here: http://lightup-analytics.com

6 releases in 1 day was .. challenging.

Adam

slbaumgartner

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

ericschimel

Mine's enabled as well... It always has been....

mariocha

Here, LightUp (pre-last update), just opened the preferences pane blank, no message.
and
Keyframe Animation cannot run saying Java Script needs to be enabled, but it is.
Adam, any clue on this JS bug ?

Chris Fullmer

RE: the test file used here - we found that the test file has a typo in it, and that is why the remote download is failing in that script. It actually is trying to reach an invalid URL

So unfortunately that isn't showing any errors once the typo is corrected.

We're still looking into this.

honkinberry

I can give you a quick example to one that isn't working if you need.

--J

driven

@mariocha said:

... cannot run saying Java Script needs to be enabled, but it is.

Being enabled in Safari, will not effect WebDialogs, which have JS enabled by default...
you can check what works in SU with something like this pasted into Ruby Console

 wwhdlg = UI;;WebDialog.new("wot_works_here", true, "wwh", 739, 641, 50, 50, true);
 wwhdlg.set_url "http://dante.dojotoolkit.org/hasjs/tests/runTests.html"
 wwhdlg.show_modal

john

TIG

@chris fullmer said:

RE: the test file used here - we found that the test file has a typo in it, and that is why the remote download is failing in that script. It actually is trying to reach an invalid URL

So unfortunately that isn't showing any errors once the typo is corrected.

We're still looking into this.
@Chris
Do you refer to Eric's post that modified some test rb/html I set up - using href=... ?
I find that it works fine in both .local and .remote versions on all OSs... except with MAC-Mavericks with just .remote...
If you explain the typo we could look at it [help us to help you...] BUT... it only fails for me on MAC-Mavericks using a .remote html - so IF it has a typo why would it work OK in the other OSs ???

driven

works on mavericks with 'dropboxusercontent vs. dropboxusercontext'
john

TIG

Yes I now have the typo - passed from another source...

That must be Eric’s Web-guy’s typo... he added that 'remote' code to an earlier test setup I wrote... however, it still works fine on all OSs [except Mavericks] with AND without that typo ???

I confirm that the corrected 'allow_actions_from_host' code does now work on Mavericks as well as all other OSs... most puzzling...

BUT this begs the questions... as to why very similar code fails in the SketchThis toolset, when its 'allow_actions_from_host' IS identical to the url that its ruby specifies...
???

Chris Fullmer

Thanks John - I think that is the typo in question.

As to why it works in all other OS's except for Mavericks.....that I don't know.

Chris Fullmer

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

Warped9

I started this discussion so I might as well put in my two cents. My experience with Mavericks so far has been generally positive. In regard to SketchUp I installed Make while keeping SU8 on hand for now. SU8 doesn't seem to run any different for me (as far as I can tell) on Mavericks than it did with Mountain Lion. However, Make does seem to run somewhat better (as far as I can tell) with Mavericks than SU8 does with Mountain Lion.

One odd thing, though. My SketchUcation Store plugin doesn't connect anymore in SU8. I just get a message saying V2 is available, but when I try to click for the update I just get an error message. I can still install extensions the old way by downloading them manually and using the Extensions Manager found in SU Preferences. I've even tried installing the V2 of SketchUcation Store through the Extensions Manager and I still get the error message afterwards when I try to use the plugin. The SketchUcation Store plugin works fine in Make.

slbaumgartner

@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

Chris Fullmer

Yeah, the developer's forum is a good place for it I think.

Still looking into it on our end, nothing new to add to the discussion yet.

Chris

TIG

It's already in the Devs' forum

Chris Fullmer

I just had my mind blown