Posts made by slbaumgartner

@thomthom said:

@slbaumgartner said:

@chris fullmer said:

@Steve - Writing to a plugin's folder on Windows can fail though, so its not really a god solution for Windows.

Chris - why would the write fail? It seems that if the user could install a plugin there, he should also be able to write a file there. I'm missing something about the real core of the problem...

Under windows the Program Files folder is locked down. They only want application packages installed - but the user should not add/remove files to it. And often users cannot add files to the Plugins folder - but Windows won't throw an error - instead place the files in the Virtual Store creating a shim which cause all sort of confusion and problems. You have to run as user with administrator rights and UAC turned off to avoid these issues.

Whoa! I didn't know about this Virtual Store/shim stuff. That sounds like Windows setting you up for problems! Simulating a write to a place you don't have permission to write (to install the plugin) then later refusing permission to write to the same place!!???

@fredo6 said:

I think the problem of security may be about creating a folder from Ruby. The most frequent issue reported is about the creation of DEFPARAM_dir in the SU Plugins directory.

Fredo

Dir.mkdir should work fine in any folder where the user has write permission.

Do you know exactly what error message they get when this fails? That would help with diagnosis. Unless you trap them in your code, the error messages will appear in the Ruby Console. Two possibilities that come to mind:

Errno::EACCES: Permission denied - <name of the dir you tried to create> This means this user doesn't have write permission for the base folder in which you are trying to create a new dir. Could happen if they've somehow gotten your plugin installed in ~/Library/Application Support/..../Plugins but you are trying to create your directory in /Library/Application Support/.../Plugins. That could happen in SU 8 and earlier if you picked up SU's default path to plugins (/Library...) where an ordinary user might not have write permission. In this situation, the plugin itself must have been installed in ~/Library because a user always has permission there. SU 2013 has changed to keep plugins in ~/Library

Errno::ENOENT: No such file or directory - <the path you gave when you called Dir.mkdir> The path you gave does not exist (the base path leading up to your new dir, which of course does not itself exist unless the mkdir call succeeds). Note that Dir.mkdir does not expand "~", so you have to do it if you want to work in ~/Library/..., e.g. "/Users/Steve/Library/..."

Hope that helps
Steve

@fredo6 said:

@unknownuser said:

On Mac, there seems to be difference between copying a file in a directory and creating the file or folder from within a program. This is a basic things for security.

From what I know of Unix, this doesn't make sense to me. Can you give me an example?

@fredo6 said:

The problem users have with DEFPARAM_Dir folder is exactly that. Ruby cannot create it, but you can create it manually.

I'll have to try that out and see if I can understand why that happens. Does this occur on all versions of SU, including 2013, or only on older ones?

@fredo6 said:

What I am looking for is a safe place where Ruby can create folders and files.

Now, if, as suggested by Chris, I use /Library/Application Support/ as the root, the question is whether the root should not be /Library/Application Support/Sketchup, so that all SU plugins could create their own subfolders there. This would be much cleaner than if I create my folder at /Library/Application Support/LibFredo6.

My feeling is that this question should be taken seriously by the Sketchup application itself and supported from Ruby so that script writers don't have to bother.

Final word: excuse my ignorance, but what is the subtle difference between /Library/Application Support/ and ~/Library/Application Support/?

Fredo

First, you should understand that "~" is Unix shorthand for the user's home directory, usually /Users/<username>. /Library/Application Support is a central folder that all users can normally read, but non-admin users may not be able to write (varies). ~/Library is by default hidden by Finder, so many users don't even know it exists, but it is owned and normally writable by the user. It is also not normally viewable or writable by other users, and is meant to hold the application settings that are personal to that user.

And, yes, you should work within a subfolder of ~/Library/Application Support, not right there in the base. SU 2013 puts subfolders in ~/Library/Application Support/SketchUp 2013/SketchUp/. For example, that's where the Plugins fol

On Mac, there seems to be difference between copying a file in a directory and creating the file or folder from within a program. This is a basic things for security. [/quote]

From what I know of Unix, this doesn't make sense to me. Can you give me an example?

@fredo6 said:

The problem users have with DEFPARAM_Dir folder is exactly that. Ruby cannot create it, but you can create it manually.

I'll have to try that out and see if I can understand why that happens. Does this occur on all versions of SU, including 2013, or only on older ones?

[quote="fredo6":3f9n25ud]

What I am looking for is a safe place where Ruby can create folders and files.

Now, if, as suggested by Chris, I use /Library/Application Support/ as the root, the question is whether the root should not be /Library/Application Support/Sketchup, so that all SU plugins could create their own subfolders there. This would be much cleaner than if I create my folder at /Library/Application Support/LibFredo6.

My feeling is that this question should be taken seriously by the Sketchup application itself and supported from Ruby so that script writers don't have to bother.

Final word: excuse my ignorance, but what is the subtle difference between /Library/Application Support/ and ~/Library/Application Support/?

Fredo[/quote:3f9n25ud]

First, you should understand that "~" is Unix shorthand for the user's home directory, usually /Users/<username>. /Library/Application Support is a central folder that all users can normally read, but non-admin users may not be able to write (varies). ~/Library is by default hidden by Finder, so many users don't even know it exists, but it is owned and normally writable by the user. It is also not normally viewable or writable by other users, and is meant to hold the application settings that are personal to that user.

And, yes, you should work within a subfolder of ~/Library/Application Support, not right there in the base. SU 2013 puts subfolders in ~/Library/Application Support/SketchUp 2013/SketchUp/. For example, that's where the Plugins folder lives.

Steve

@driven said:

@slbaumgartner said:

Puzzling...why not for you?

not sure, do you have a dropbox to check if there's a short circuit trying to use your own???

does that even make sense?

john

I don't have any experience with dropbox, so it's all guessing on my part. But it doesn't make sense to me that you would be blocked from accessing your own dropbox. Has that happened to you in any other context? Your code worked for me in both SU 8 and SU 2013 Make.

Steve

@chris fullmer said:

@Steve - Writing to a plugin's folder on Windows can fail though, so its not really a god solution for Windows.

Chris - why would the write fail? It seems that if the user could install a plugin there, he should also be able to write a file there. I'm missing something about the real core of the problem...

@chris fullmer said:

And up until 2013, it should have been equally likely to fail on Mac as well, because plugins were being written to /Library/Application Support, which is public, which requires admin rights. Only since 2013 have Plugins been written to ~/Library/Application Support/..., which is completely writeable by the current user.

Yeah, /Library/Application Support really should be only for files installed along with the app itself that need to affect all users. User-installed extensions, etc, should have been in ~/Library/Application Support all along. Before anybody bites my head off, I know that there have been previous discussions here disparaging ~/Library, but I think they were and still are wrong. However, that does leave the question on a shared computer of where/how to install extensions that you want to affect all users' instances of SU.

@chris fullmer said:

Also, we're not writing in iOS, so their extreme sandboxing isn't a concern here (yet?). It will be interesting to see what Maverick implements. But its hard enough to develop for backwards compatibility and current compatibility....forward speculative compatibility might be a little too speculative for my taste.

Chris

PS - for the record, I have nothing to do with Macs and the decisions we make about how we handle the Mac files system, so don't let me ignorance scare you too much. They won't let me ruin SU on your Mac any time soon

Yeah, I know SU isn't for iOS, just thought I'd throw that in as an example of how Apple's thought processes may be running. OS X is ultimately a wrapper around a full Unix system, and without losing all of the users (like John and I) who like to step behind the curtain now and then, there are limits on how far Apple can go.

And don't worry - whatever you come up with to mess up SU on my Mac, I'll find a way to defeat it

Steve

@driven said:

@Tig

I tried the file you linked to to download from my Dropbox Public Folder, but I get this message[attachment=0:2x8b9f01]<!-- ia0 -->2013-06-19 06.51.51 pm.png<!-- ia0 -->[/attachment:2x8b9f01]
and yes it ends in Grid.skp

to get it to run at all, I changed line #32,
any ideas?

 class LoadHandler
> 
>    def onPercentChange(p)
>      Sketchup;;set_status_text("LOADING;    " + p.to_i.to_s + "%")
>    end
> 
>    def cancelled?
>      # You could, for example, show a messagebox after X seconds asking if the
>      # user wants to cancel the download. If this method returns true, then
>      # the download cancels.
>      return false
>    end
> 
>    def onSuccess
>      Sketchup;;set_status_text('')
>    end
> 
>    def onFailure(error_message)
>      # A real implementation would probably not use a global variable,
>      # but this demonstrates storing any error we receive.
>      $last_error = error_message
>      Sketchup;;set_status_text('')
>    end
> 
>  end
> 
>  # Replace this with a real URL...
>  url = "https://dl.dropboxusercontent.com/u/25114184/Dynamic Components Training/Tile Grid.skp"
>  load_handler = LoadHandler.new
>  Sketchup.active_model.definitions.load_from_url url, load_handler
> 
>  if $last_error == nil
>    last_def_id = Sketchup.active_model.definitions.count - 1
>    loaded_definition = Sketchup.active_model.definitions[last_def_id]
>  else
>    UI.messagebox("Error; " + $last_error.to_s)
>  end

it's an active link if you want to test against it...
john

@john, the above ran ok for me - added the Tile Grid to the components in my model and did not raise any errors. Puzzling...why not for you?

Steve

@chris fullmer said:

Talking it over a little bit here with a Mac person, I still think that the ~/Library/Application Support/ folder is the right starting point. It exists on all Macs, and is specifically designed to be the location that support files get saved to. To me, that is the definition of what Fredo is looking for, and it is sanctioned by Mac. So it CAN'T be against their own "Every app is an island" viewpoint, or else they wouldn't have created it, right?

On iOS, apps are quite strictly sandboxed. Each app gets its own virtual disk image and can't read or write anything outside that image.

But in Mac OS X, this is not yet the case. An app can read and write anything for which the user has adequate permission anywhere on any drive. And, using shell scripting such as John has provided, a plugin can ultimately bypass the app's own API and rules to execute arbitrary UNIX commands.

The sandboxing rules today on OS X only exist as conventions that developers are asked to respect (required to respect if their code is published via the App Store). But, as John has alluded, Apple is trying to beef up the sandboxing because so many apps spew files all over the disk and this makes it difficult or impossible to completely remove an app. Rumor is that the next edition ("Mavericks", expected in the Fall) will have some changes in this regard.

So, whereas ~/Library/Application Support/<appnane>/... has been the conventional place for applications to save helper files, this could change.

Based on all of this, it seems to me that the only place that simultaneously provides:

• assured read and write permission for the user
• logical/code consistency between Windows and Mac
• support within SketchUp for readily finding the folder by a plugin

is a plugin's own subfolder within whatever folder SketchUp is using to store user-added extensions. That is, when you tell SU to add an extension, SU itself chooses the appropriate folder ("Plugins" somewhere) and unzips your rbz file there. You have to have write permission in that folder, else SU couldn't install the extension. At that point your plugin code can query to find out where it was installed and can create more subfolders as well as write and read arbitrary files there. The plugin should not hard code any path such as "C:\Program Files\SketchUp\Plugins" or "~/Library/Application Support/SketchUp 2013/SketchUp/Plugins". It should use either Sketchup.find_support_file(...) or File.dirname(FILE) or something similar to get SU to reveal where the extension was loaded, and then use relative paths from there.

That approach both allows arbitrary files to be written and read, but also will survive if SU is compelled to change the physical folder where extensions are stored because OS security rules were tightened.

Steve

@driven said:

@slbaumgartner said:

but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

@Steve,
that's exactly what this pair does, your entry in the com.sketchup.SketchUp.plist

 result = Sketchup.write_default "section",
>    "variable", "my_value"
> result = Sketchup.read_default "section",
>  "variable", "default"
> 

in the .plist that shows as

	<dict>
> 		<key>variable</key>
> 		<string>"my_value"</string>
> 	</dict>

john

Which leaves me somewhat confused about what fredo is seeking to accomplish. Unless you are determined to keep your info somewhere separate from SketchUp's "defaults", what's the problem with using these methods?

Steve

@fredo6 said:

@slbaumgartner said:

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

I understand.
But where can the persistent parameters be saved on Mac?
What are other applications doing?

Fred

On a Mac under OS X, the conventional/approved place for user configuration parameters is a .plist file in ~/Library/Preferences. The file name starts with a dot-separated sequence like a reversed domain name that identifies the relevant app, and then adds more segments to specify what about that app. For example, com.trimble.sketchup.fredo.magictool.plist.

There are API calls for storing and retrieving info from plist files, but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

Ya gotta love it! The following works just fine on the Mac, even though h is the shortcut for the pan tool, but fails on Windows by switching to pan.

<span class="syntaxdefault"></span><span class="syntaxkeyword">class&nbsp;</span><span class="syntaxdefault">MyTool<br />&nbsp;&nbsp;def&nbsp;onUserText</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">rawtext</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">view</span><span class="syntaxkeyword">)<br />&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">begin<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">messagebox</span><span class="syntaxkeyword">(</span><span class="syntaxstring">"VCB&nbsp;held&nbsp;#{rawtext}"</span><span class="syntaxkeyword">)&nbsp;</span><span class="syntaxcomment">#&nbsp;show&nbsp;the&nbsp;raw&nbsp;input<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxkeyword">if(</span><span class="syntaxdefault">rawtext</span><span class="syntaxkeyword">[-</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">].</span><span class="syntaxdefault">chr&nbsp;</span><span class="syntaxkeyword">=~&nbsp;/[</span><span class="syntaxdefault">wh</span><span class="syntaxkeyword">]/)&nbsp;</span><span class="syntaxcomment">#trap&nbsp;and&nbsp;strip&nbsp;key&nbsp;characters&nbsp;if&nbsp;present<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">key&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">rawtext</span><span class="syntaxkeyword">[-</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">].</span><span class="syntaxdefault">chr<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;text&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">rawtext</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">chop</span><span class="syntaxkeyword">!<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">text&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">rawtext<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">text</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_l&nbsp;</span><span class="syntaxcomment">#see&nbsp;if&nbsp;text&nbsp;is&nbsp;convertible&nbsp;to&nbsp;a&nbsp;length<br />&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">rescue<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxcomment">#&nbsp;can't&nbsp;process&nbsp;the&nbsp;VCB&nbsp;input.&nbsp;&nbsp;This&nbsp;could&nbsp;be&nbsp;because&nbsp;the&nbsp;trailing&nbsp;character<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;isn't&nbsp;one&nbsp;of&nbsp;the&nbsp;key&nbsp;characters&nbsp;or&nbsp;because&nbsp;the&nbsp;text&nbsp;isn't&nbsp;a&nbsp;number<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">beep<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;puts&nbsp;</span><span class="syntaxstring">"Cannot&nbsp;convert&nbsp;#{rawtext}&nbsp;to&nbsp;Length&nbsp;with&nbsp;optional&nbsp;key"<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">value&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">nil<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sketchup</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">set_status_text&nbsp;</span><span class="syntaxstring">""</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">SB_VCB_VALUE<br />&nbsp;&nbsp;&nbsp;&nbsp;end<br />&nbsp;&nbsp;&nbsp;&nbsp;</span><span class="syntaxkeyword">return&nbsp;if&nbsp;!</span><span class="syntaxdefault">value<br />&nbsp;&nbsp;&nbsp;&nbsp;UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">messagebox</span><span class="syntaxkeyword">(</span><span class="syntaxstring">"Got&nbsp;value&nbsp;=&nbsp;#{value},&nbsp;key&nbsp;=&nbsp;#{key}"</span><span class="syntaxkeyword">)<br />&nbsp;&nbsp;</span><span class="syntaxdefault">end<br />end<br />Sketchup</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">active_model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">select_tool</span><span class="syntaxkeyword">(&nbsp;</span><span class="syntaxdefault">MyTool</span><span class="syntaxkeyword">.new&nbsp;)&nbsp;</span><span class="syntaxdefault"></span>

Steve

@al hart said:

You can download a copy from here:

http://www.renderplus.com/downloads/SimpleExtension.zip

It has a read me file, and with a little work to get it to work, it actually works.
(You have to have Ruby installed on you own machine when you compile and link it, for example)

SketchUp sent it to me about 6 years ago, and although they don't publish or support it, they did give me permission to pass it on to others.

If you get stuck getting it to work in Windows, I can help. But I could sure use some help from someone who knows more about compiling, etc. on the Mac than I do to get a version running for the Mac

This sounded interesting, so I downloaded it and took a quick look. It creates a Windows DLL (dynamic link library). The organization and structure of a DLL are very Windows-specific. Mac also has dynamic shared libraries, but their organization and structure are completely different. It would require a significant rewrite to get this over to the Mac; no doubt feasible, but way out of my depth!

Steve

@stuartmitch said:

For some reason, since upgrading to Apple Mountain Lion, I have been unable to dock any plug-in toolbars to the top or side of the SketchUp workspace. I have just upgraded to SketchUp 2013 and I still have the same problem (thought it might go with new release).

Has anyone got a solution for this?

Cheers...>Scotty

What you may be overlooking is that the MDI interface on the Mac is not amenable to "docked" toolbars. The same instance of SketchUp can have several models open, each in its own window, at the same time. If you could "dock" a toolbar to a single window, it would cause even more confusion. Did you mean it to apply to all open models (in which case docking has no advantage over the existing Mac style), or really to just this one window (and why do that)?

So, I think the only sensible solution is to adapt to the Mac way of handling this.

[edit] Or did you mean that you'd like the toobars to attach to the edges of the desktop? That would make sense.

Steve

Chris, thanks for your response!

@chris fullmer said:

@slbaumgartner said:

From a first look at SU 2013, I am stumped. Ok, the extension warehouse provides an official, supported way to get your Rubies out to the world, and the revised C SDK is claimed to be better. But other than that, what new does 2013 provide for developers?

Hey Steve, those are very non-trivial improvements that you just brushed off like they were nothing'. Completely re-writing the .skp reading and writing code that SketchUp uses for its own files, making that available through the new sdk, and then ALSO providing a built in extension warehouse to make plugins instantly visible to millions of people get me excited every time I think about it!

Sorry Chris, I didn't mean to slam those items. I guess I was in a rush to get to the others.

I'll be blunt here: I suspect that the SDK rewrite had a lot more to do with improving Trimble's ability to integrate SU with their other tools than with anything the majority of current users and developers needed or wanted.

@chris fullmer said:

You probably don't want me to say it, because I should probably just "know" it already, but what specific issues need to be fixed? If there are specific methods that are broken, I can always try to put in a request to get them fixed.

Just browse this forum for a while and you will find dozens (if not hundreds) of discussions of issues with the Ruby API and workarounds that people here have developed. There are also lots of posts by the Sketchucation expert developers clarifying things that the API documentation misstates, underexplains, or simply doesn't mention. We always had the impression that the SketchUp team followed boards such as this and payed attention. Were we wrong? There are issues that were reported long ago that still remain, so far as I know.

@chris fullmer said:

Thanks for your honest feedback, continued support and development in SkethUp,

Chris

You are welcome.

Steve

From a first look at SU 2013, I am stumped. Ok, the extension warehouse provides an official, supported way to get your Rubies out to the world, and the revised C SDK is claimed to be better. But other than that, what new does 2013 provide for developers?

• So far as I can see, the Ruby version is still the same (1.8.5 on the Mac, yet)!
• I can't find any discussion of changes to the Ruby API. Have any new classes or methods been added? Is there any new functionality? Anything removed or altered?
• I can't find any discussion of fixes to bugs in the Ruby API. Am I expected to experiment to see which of the old workarounds are still needed and which calls still don't work as documented?
• The nice developer console and TestUp remain unofficial addons that appear to have dropped off the radar some time last fall.
• There is no mention about any progress on all of the notorious issues in WebDialogs, especially Windows vs Mac portability.

It would seem that if there are important changes taking place behind the scenes, even we developers who helped make SketchUp the triumph it has been are being kept in the dark.

Steve

@archheni said:

@thomthom said:

@archheni said:

Every restart will wipe out all non-native plugins and tools..

?
What's being wiped out?

..All non-native plugins on the customized toolbar.

This looks to me like a long-standing issue has simply continued. Every time I start SketchUp on the Mac, it opens a blank file window with a toolbar that contains only the built-ins. If I close that file and do a File->New, the customized toolbar is restored. Despite numerous complaints in the past, it appears that 2013 does nothing about this...

@mwm5053 said:

I'm kinda disappointed, I don't see much diference except change of icons maybe someone can start showing some improvements. Maybe a list or hidden finds of improvements.

Ditto. I notice that the Mac version still uses Ruby 1.8.5, which isn't even the version installed standard on OS X. Other than the bump in license terms (no commercial use of any sort for the free version) and price ($590 for pro), the only visible change seems to be the extensions warehouse.

All you excited beta testers, can you now spill the beans and tell us what we should be excited about?

Dan, I suspect there was (or maybe still is) a glitch on the site. The first time I downloaded, I got the Windows installer exe, but on the second try I got the Mac dmg. I didn't do anything different, so I think they probably fixed it.

Steve

@alexschreyer said:

Forgot to mention:

• Yes to Find/Replace. Next version, though...
• Undo is in there. Just make sure the editor window is highlighted when you do Command-Z

Cheers,
Alex

I find that Command-Z works only for text you type yourself, not for snippets inserted from the menu. You can highlight a section of code and hit delete, though.

Steve

@alexschreyer said:

Could anyone with a Mac check this, too, please... I did some Mac checks but I develop on Windows.

Cheers,
Alex

More tidbits:

The options window isn't sized to the contents and isn't scrollable. I had to stretch it out before I could see all the items.

On a Mac the editor keeps disappearing behind other windows. I'd like it better if it were modal (which, on a Mac, just keeps it on top, it doesn't block events to other windows).

The tooltips that say "Alt-..." are wrong on Mac. They should be "Command-..." instead. For instance, "Alt-S" inserts a German Eszett!

Command-S gets "Save As", even when you have been editing an existing file.

The snippet Mac or PC? has syntax errors. Presumably you meant to have :windows and :mac as symbols, but there is a space between the : and the name.

Is there a find or find+replace capability? If so, what triggers it? No standard key press seems to get there. Seems like a pretty basic editor function. Undo would also be very helpful, especially if you make a mess by inserting a snippet at the wrong place!

The syntax highlighter picks out SketchUp keywords out of context and without regard to capitalization. So, for example, if you name a variable "entities", it is highlighted as a keyword. Should only happen for "Entities" and "xxx.entities" (without getting into whether it is a good idea to name variables the same as keywords).

I was confused by the "explore current selection" and "List object's attributes" buttons until I discovered that they pertain to a selected object in SketchUp, not in the editor!