hmm... I was working on something like this a while ago.... can't remember right now how far I got...

Yea, it would be good to see more community projects going.

Yea, when we get the new system up we need to review everything - and input from the users of the docs is valuable.

I got a couple of repositories myself with observer and webdialog bugs. Had to file them somewhere with some structure.

Just so you're aware, we're looking into new solution for the API docs. I don't know of any time frame, yet though.

What about Select Curve? http://sketchucation.com/forums/viewtopic.php?p=273423#p273423

@rv1974 said:

The stuff does not enter the memory buffer! (though it indeed get selected).

Wait, it it gets selected, but that is not what you mean by "memory buffer"?

Ah, the docs are wrong. Why am I not surprised...

@unknownuser said:

Edit2: It doesn't appear to take a hash-options.
However, the poorer quality only seems to happen for JPEGs. Saving it as a PNG maintains the quality but completely ignores the size arguments.

whut whut?? A bug you say?

Are you using Ruby threads? Threads in Ruby 1.8 are green threads, meaning not native threads.

Can you elaborate on how you implemented a progressbar?

Selection Toys let you select everything.

Definitely upgrade your SketchUp version.

One problem is that the Set class of the Standard Library conflicts with the Set class that ships with SketchUp and will break plugins that tries to use the SketchUp Set class - such as Sandbox Tools.

New chapter for the Lost Manual.

Pi is part of the Math module: Math::PI

Also, beware that there is an important difference between and and && as well as or and ||. https://www.tinfoilsecurity.com/blog/ruby-demystified-and-vs

I saw Martin's writeup, but I don't think he got it all right.

In TestUp's case the @webdlg variable returns the same instance as the dlg argument from the callback. There is no difference to them. When you have stored the webdialog in an instance variable the webdialog argument isn't needed. (Saying that, you could create a Proc you reuse to multiple instances of an webdialog - in which case that argument is useful.)

In terms of the webdialog being ready - when you call webdialog.show you cannot interact with the content of the webdialog immediately. You have to wait for the full DOM to be ready - this is why we need to make a callback from the webdialog back to ruby and perform the rest of the work there - such as populating the webdialog with values or reading from it. I think this is what Martin was talking about.

When an HTML document is created the various events we can use is:

• Script call from the bottom of the document. (the event would trigger right before the closing HTML tag is done.)
• DOMContentReady which triggers when the HTML DOM three is processed and fully ready, but images and external CSS might not be ready.
• body.onload that triggers when everything is ready and loaded. This would be triggered last.

So since DOMContentReady works, which triggers before body.onload, then it is very strange that body.onload cause this blank window. Which also means it's not the async nature of OSX's callbacks. Maybe DOM modifications during body.onload mistriggers some events within WebKit - the onload event triggers, but maybe DOM modifications interfere with the event that cause WebKit to redraw.

And given that it works under IE it appear to be an WebKit bug related to the onload event. Because there is nothing that should say, logically, that it shouldn't work. When events that triggers earlier works, then why would the late onload not trigger?

It could even be a WebKit issue only seen when used as WebDialog. Who knows.

But, what if another plugin does the same thing?

@slbaumgartner said:

Was the HTML changed? The version I downloaded last winter has this body (after moving bodyLoad()):

That A element is the Run button. Elements doesn't have to have content to render, one can set the size and style of elements regardless. And in any case, the colour of the BODY element should have rendered.

@slbaumgartner said:

Has Apple distributed a new version of WebKit? I know there was an update to Safari, but the WebKit accessed by other apps is not the same as Safari.

I'm not sure about Safari Update vs WekBit update, but I do know that one update, whatever it was, some while ago broke WebDialog.set_html for a while.

I did a quick test of hooking up bodyLoad() to DOMContentLoaded

  // Added this snippet to the end of TestUp's script in the head.
  document.addEventListener( "DOMContentLoaded", function(){
    bodyLoad();
  }, false );

That worked perfectly. So it does appear to be an issue with the onload event under OSX.

Mind you that DOMContentLoaded isn't working so great with older browsers and it's a bit complicated to make it work cross browser. Another reason for projects to use jQuery or similar to take care of this stuff. For now I'll just make TestUp call bodyLoad() from the bottom of the page.

Hmm.. I don't know. I use similar method for my own WebDialogs, but I always use jQuery and use the .ready() event which triggers when the DOM is ready - which should trigger even before onload because onload triggers when all external resources such as images and scripts are loaded. (Not a big deal with local resources, but when downloading from the web makes a big difference.) And I've never seen that behaviour then.

The initial TestUp HTML isn't completely empty, it has the basic framework for the UI element - the CSS styles should have applied it's style to that.

I think someone mentioned that it was working fine before, (and it does work fine under Windows), so I somewhat suspect there's some change in WebKit's onload event that cause some unexpected mistrigger - in terms of kicking in the redraw for the window - maybe some optimization gone wrong...

If only we had a simple bare bone example, that would make it easier to compare. It's difficult with TestUp to change one thing and not break everything.

If you extend and instance with module "FooBar" then you can use instance.is_a?(FooBar)