[Patch] to "sketchup.rb" (beta) v 1.1.0

Dan Rathbun

Call for testing, critiques, ideas, additions, etc.

This package is a patching extension that fixes certain methods in the "Tools/sketchup.rb" file.

It consists of a extension registration script "!!_sketchup_rb_fix_ext.rb" in one of your plugin directories (ie, one of the path elements in the **$LOAD_PATH** array.)

The registration script adds 4 patches to the Preferences (dialog) > Extensions (panel) list.

The patches reside in a "_patches/sketchup_rb" sub-directory, of a plugins directory.

I have separated each patch into it's own file, so it can be switched on/off, tested and updated individually.

sketchup_rb_patches_v1_1_0.rbz
ver 1.1.0 : Fixed the omission of the " require('extension.rb')" statement, in the "!!_sketchup_rb_fix_ext.rb" file.

Details:
(These are the descriptions that appear in the Preferences dialog.)

Patch: 'sketchup.rb' add constants

This patch adds useful global boolean platform constants MAC, WIN, OSX and PC to the ObjectSpace, so they can be used by all plugin authors. On PC, it also defines a HOME environment variable, if not defined. A HOME variable allows ~ (tilde) path expansion using File.expand_path("~/some/dir/path").

Patch: 'sketchup.rb' fix add_separator_to_menu()

This patch allows storing menupath names for submenus. (Handles multiple submenus with the same name.) Extends the use to tracking multiple separators per menu, if desired. Adds method argument validation.

Patch: 'sketchup.rb' fix inputbox()

This patch does more argument list validation, and issues more informative exception messages, than UI.inputbox() does. The inputbox() wrapper did no argument list validation at all; and coding errors would result in a messagebox loop, that required killing Sketchup with the Task Manager.

Patch: 'sketchup.rb' fix require_all()

This patch does more validation, checks for directory existence, and if the directory has files to load. The method now explictily returns useful values, depending on what was done. Revised the load exception handling, algorithm so that the load loop can continue loading files, if an error occurs in single file. (It previously exited the loop without loading the rest of the files, if any load errors occured.)

driven

hi Dan,

when installed straight from 'Downloads' folder using Sketchup >> Preferences >> Instal Extension

the folder and files are loaded into "/Library/Application Support/Google SketchUp 8/SketchUp/Plugins"
on next startup I'm getting...
Error Loading File !!_sketchup_rb_fix_ext.rb uninitialized constant SketchupExtension

john

Dan Rathbun

Thanks John.

Dumb mistake on my part. I should have had a
require('extensions.rb')
at the start of the registration script, just below the require('sketchup.rb')

On my machine I actually had another file loading ahead of it that loaded 'extensions.rb',... always pays to have someone else try it on another setup.

I'll fix that.

DONE

Dan Rathbun

Is everyone else seeing Sketchup::require push full paths into $" (aka $LOADED_FEATURES,) array for v 8 ??

Aerilius

I see many full paths, but extensions.rb is ok.
**```
$LOADED_FEATURES
["langhandler.rb", "sketchup.rb", "LibTraductor.rb", "LibTraductor.rb", "libtraductor.rb", "extensions.rb", "C;/Programme/Google/Google SketchUp 8/Plugins/LIBFREDO6_Dir_35/Lib6Core_35.rb"]

As a side note: Should we plugin writers use the full path or only the basename? My thought was basename-only could lead to namespace problems if two plugins have files with the same name :unamused: but maybe the basename really makes more sense?


@dan rathbun said:

> This patch adds useful global boolean platform constants MAC, WIN, OSX and PC

Shouldn't we be careful not to mix hardware and operating system platforms? The official unambiguous names (by the OS vendors) are "**Win**"(dows) and "**OSX**" (not anymore Mac OS). The problem I see is that PC is absolutely meaningless and a Mac does also run Windows and everything else.

Dan Rathbun

@aerilius said:

The problem I see is that PC is absolutely meaningless and a Mac does also run Windows and everything else.

And a PC can run Linux ... and other OSes.

I agree.. (and we've had this discussion before,) some are just so "comfy" calling one a Mac and the other a PC (just like the Apple TV ads,) that I gave up the technical argument, and just defined all four.

I important thing is for Sketchup, we need a fast (boolean) test, that everyone can use and rely on. (And not the crappy slow string example like Google still has on the FAQ page.)

Dan Rathbun

@aerilius said:

As a side note: Should we plugin writers use the full path or only the basename? My thought was basename-only could lead to namespace problems if two plugins have files with the same name, but maybe the basename really makes more sense?

First of all... authors should be putting their files within an author filespace. "author/plugin_this" "author/plugin_that"

Secondly... $LOADED_FEATURES is "supposed" to get the RELATIVE paths, the same way that require() got them.
What Google did with Sketchup::require has made things worse. It has made Kernel.require incompatible. We have to use one or the other. I choose the Ruby standard, myself.

Now.. this is all separate from the menu issue and $loaded_files:

Third... if your using $loaded_files from "sketchup.rb", yes there could be conflict if you use only basename. BUT that array is really just a string array. None of the elements are actually used to load files. You could actually prepend all you basenames with some GUID that you use for your plugins.

Fourth.. why not, if you use a toplevel namespace, create your OWN @@loaded_files within that module. Then you don't have to share it with the rest of the world.

thomthom

@dan rathbun said:

What Google did with Sketchup::require has made things worse. It has made Kernel.require incompatible. We have to use one or the other. I choose the Ruby standard, myself.

I've started to move to Sketchup::require since I from time to time need to deal .rbs files. As you say, use one or the other, and require can't load .rbs files.

thomthom

@dan rathbun said:

The registration script adds 4 patches to the Preferences (dialog) > Extensions (panel) list.

Why have a patch in the extension list? Why would an end user ever need to enable/disable this? Don't you think it can cause confusion?

Dan Rathbun

@thomthom said:

@dan rathbun said:

The registration script adds 4 patches to the Preferences (dialog) > Extensions (panel) list.

Why have a patch in the extension list? Why would an end user ever need to enable/disable this? Don't you think it can cause confusion?

@dan rathbun said:

I have separated each patch into it's own file, so it can be switched on/off, tested and updated individually.

Formost.. for testing.

But as sometimes happens, patches can either introduce other unforseen issues, or perhaps a very popular plugin relies on some quirkiness that the patch fixed. Because it may be large and complex, the author of this "example" popular plugin, needs time to update his code.

So the patch can be switched off.. until an update is issued.

Patches, in general: I have thought many times upon a patching system, similar to the extension system. I imagine it having it's own checklist, separate from the plugin checklist.

[Patch] to &quot;sketchup.rb&quot; (beta) v 1.1.0

[Patch] to "sketchup.rb" (beta) v 1.1.0