I don't know if it's really too unfortunate -- even if you could manage to do that, it's way too much of a hack to consider for any production plugin. And even then, it would be Win32-only.

Better than that would be if both those and WebDialogs were able to be docked into the SketchUp window frame. This is the part of SketchUp that makes me feel like I'm using Win95.

@unknownuser said:

Microsoft made something OSX compatible...?

The official SL support list is, I believe: IE 6/7/8, FF 2/3, Safari 3/4, and Chrome. Maybe Opera now too, or in the near future.

@thomthom said:

JD - your Silverlight UI - do you use a ready made framework? Skinned? Or did you build one yourself?

I did write this myself.

@adamb said:

Looks cool but you've stopped any possibility of doing this on non-Windows platforms.
No?

No, Silverlight runs fine run on Windows or OSX. There is spotty support for it in linux, but it lags the official SL version by a point or two. But linux was not an issue here anyway.

Just a guess, as I'm in no way a Flash guy, but I think you may be thinking of Flex, rather than AIR.

Ah, I really should have inferred that. It's basically just a runtime for running Flash out-of-browser, isn't it?

I'm not familiar with that, do you have any links?

Yes, they do.

@thomthom said:

Ok - modifying the image is something one can not do in pure HTML+JS+CSS...

While it's nice to be able to use HLSL to manipulate images in the browser, there are other reasons as well.

The UI part of the project is about 70K lines at the moment, supports undo/redo for absolutely all actions, and operates in a fully modeless fashion within SketchUp. Imho, it would be much more difficult and error-prone to try to do this in JS than in C#. Also, the UI works exactly the same on SU6/7/8/Win/OSX.

For projects smaller than this, of course I agree that HTML/CSS/JS would often make much more sense.

@thomthom said:

I don't see anything that can't be made with regular HTML+JS+CSS.

In my defense, there are some things:

[flash=285,294:12en6b6s]http://downloads.simplesoftwaresystems.com/sketchup/tex.swf[/flash:12en6b6s]
(I couldn't make this auto-play, so right-click)

Ruby just nees more methods wrapped. On the C++ SDK's ISkpCamera, you have:

virtual HRESULT STDMETHODCALLTYPE 
    get_FieldOfViewIsHeight(/*[out]*/ BOOL *pVal) = 0;

Update: this bug is still present in SketchUp 8.

Module.foobar is an alias for Module::foobar, which is itself an alias for Ruby::is_fubar?, which incidentally, always returns the TrueClass instance, for which jessejames's above statement is an alias.

On Windows, setting <param name="windowless" value="true" /> in your Silverlight object tag (i.e. in your html page) will allow the keyboard to work correctly. The same is not necessary on OSX.

@unknownuser said:

not sure if this is a bug or not...

I'm guessing that it is:

As red_shift says, it becomes a problem when using the Maxwell plugin because the plugin relies on the SU camera's aspect_ratio to allow the user to see how the film size they are using in their Maxwell camera will affect their rendered output.

That's how this affects Maxwell users -- however, it is not Maxwell-specific; any script or plugin which relies on SU's Camera::aspect_ratio= method to accomplish its goal will bump into this issue.

Apparently, having a custom aspect ratio set on the camera will cause 2D rendering to randomly print portions of the 'grey box' overlays on the output image. This seems only to happen on OSX (tested here on OSX Snow Leopard, SU Pro 7.1.4870).

Repro steps:

1. start SU
2. open ruby console
3. type 'Sketchup.active_model.active_view.camera.aspect_ratio=1.5'
4. hit enter
5. unless the viewport is exactly 1.5:1, you should see gray bars on two edges
6. go to File > Export > 2D Graphic > JPG, PNG, TIFF

At lower resolutions (i.e. 400px or so), all seems to be well. Go larger, however, and the gray bars that indicate the camera aspect ratio are printed in random patches over the output image.