Alternate directory for Plugins

fredo6

Hi,

Till SU8, Sketchup relies on a 'hard-coded' location for the Plugins, which is typically in C:\Program Files\Google\Google SketchUp X\Plugins. This has tow main drawbacks:

This Plugin folder being in the System area, it may be protected for write access. I have heard that schools and some companies usually have PCs where access to C:\ is disabled.
The Plugin directory is attached to each version of Sketchup. So if you use several SU version, in particular for transition, you have to install and then update plugins in each application domain.

I have been using for a while now a small script to overcome this situation. My requirement was primarily to be able to have a single plugin directory where I could easily test SU6, SU7 and SU8 without updating files for each application.

The script, called 000RedirectPlugin.rbis standalone and fairly small. The prefix by '000' is just there to have it loaded the first one. 000RedirectPlugin must be installed in the Plugins folder of each SU application (that's the only requirement).
See This thread for download.

It performs the following:

Install a menu "Plugins Alternate Directory" in the Windows main menu. This allows the user to define the alternate directory via a small dialog box.
if an alternate directory is defined, then 000RedirectPlugin will prepend this directory to the general Ruby path(the one which is defined in $:). This will ensure that when Sketchup starts up, plugins will be searched first in this alternate directory.

Note that the script has no dependency on LibFredo6. It is neutral and could apply to any script.
Also, it does not prevent to have plugins in the regular default SU plugins folder (as this location is still in the Ruby path).

The issue for Script developers is that not all scripts are today compatible, in particular when they rely on Sketchup.find_support_file to find the location of files.

It is however quite easy to make them independent of the default Plugins directory by relying on __FILE__at startup instead, which allows to get and store the root directory where the plugin is loaded from, and then easily retrieve the companion files (like images, and other scripts).

Since 18 months, all my scripts are compatible with an alternate drectory and do not depend on Sketchup.find_support_file.

Before I release it to the community, I'll be interested to get a feedback from all scripters.

Fredo

thomthom

I have a similar setup. Though I currently use it for my own plugin I develop. I use version control so I put my plugins into separate locations.

But I also ensure that my plugins base their paths from FILE and not the SU Plugins folder.

TIG got a similar setup, I think he said, loading from a USB stick or network location.

@unknownuser said:

if an alternate directory is defined, then 000RedirectPlugin will prepend this directory to the general Ruby path (the one which is defined in $:). This will ensure that when Sketchup starts up, plugins will be searched first in this alternate directory.

Is there a benefit of having the alternate directory processed first?

TIG

Yes, I use a similar set up for my Uni students who can't access the main Plugins folder on there Uni servers.
They have a mapped login on H:\ so a special Ruby I wrote is installed by their IT gurus into their otherwise inaccessible main Plugins folder - this adds "H:\Sketchup_Plugins" to the $LOAD_PATH array at startup and any scripts they have in their own folder are also auto-load, as will 'load' used later from the Ruby Console without needs to specifically include the full folder path.
As Fredo says, you must ensure that any code in these 'personal' scripts placed in this additional folder uses 'FILE' to get the relative paths, rather than '.find_support_file()', which would incorrectly look in the main Plugins folder and then fail to load stuff properly etc...

fredo6

Thanks for your remark.

Actually, my questions were more related to users. I am sure any developer has its own set up and tricks to get organized according to its development workflow. This is why I talk about it only now.

@DanThe alternative path is a full path. So on Windows, it will include the drive letter and the second charater of $:[0] is indeed a column. By the way, some plugins add their own path to $LOAD_PATH, for instance WxRuby.

@Tom
You have a good point on whether the alternate path should be first or last. I thought about it and found no reason why it should be one or the other, just a matter of deciding on precedence (the plugin can be renamed ZZZRedirectPlugin.rb) . The only constraint is however that scripts are not loaded twice. This is why, in 000redirectPlugin.rb, the script make sure that the load path recorded at 'require' time (i.e. shown in $")is relative to the directory of loading, not to an absolute path.

Fredo

Dan Rathbun

I see your inserting the new path as the first member of the $: array.

Just be aware, that because Google hardcoded the DC package to test the 2nd character of the first path in the $LOAD_PATH array to determine the platform. (I know it's a weak test..) If the character is not ":" then the DynamicComponent package will believe the plaform is a Mac.

So your plugin could lead a user to "break" the DC extension on PC, if they don't have a drive letter and colon at the beginning of $:[0]

The DC extension can be patched:

if defined?(DynamicComponentsV1)
  class DynamicComponentsV1

    @is_mac =( RUBY_PLATFORM =~ /(darwin)/i ? true ; false )

  end # class

  class DCObservers

    @known_versions.each_value {|dci|
      dci.instance_eval %q[
        @is_mac =( RUBY_PLATFORM =~ /(darwin)/i ? true ; false )
      ]
    }

  end # class
end # patch

The patch needs to load AFTER the DC extension loads.
EDITED: The instances need to be updated as well, since the variable @is_mac will have already been created, and changing the class defintion would have no effect on those instances already created.

Your example seems complicated when a simple script like I showed can do the job:
http://forums.sketchucation.com/viewtopic.php?f=180&t=31060&start=45#p314470

Dan Rathbun

BUMP

Fixed Patch I showed in previous post (to account for dc instances already created):
http://forums.sketchucation.com/viewtopic.php?f=180&t=35886&p=316176#p316176

Dan Rathbun

@unknownuser said:

@Dan The alternative path is a full path. So on Windows, it will include the drive letter and the second charater of $:[0] is indeed a colon.

I did not see you using File.expand_path so I thought perhaps a user could enter a relative path.

@unknownuser said:

By the way, some plugins add their own path to $LOAD_PATH, for instance WxRuby.

WxRuby (and the WxSU implementation,) is a library not a plugin. There is a big difference.

fredo6

@dan rathbun said:

I did not see you using File.expand_path so I thought perhaps a user could enter a relative path.

You are right. I fixed it. Thanks for the advice.

Again, the question is whether you all think that this functionality is useful for users(for developers, I know they can manage) or if it is going to add confusion and more troubles. This is why I opened the thread in the Developers section of the forum.

Fredo

Dan Rathbun

For users, I think putting the option under the Windows menu, may be confusing. Sketchup should have a "Settings" or "Options" menu, but well... my 2nd choice would be under a "Options" submenu of the "Plugins" menu.

Is it useful ?? Well yes... I am putting 3 folder open buttons on my Console Toolbar ("Shared", "User" and "Custom",) that can be configured to open certain folders much the same way you have done for specifying them. But the UI.inputbox just cannot do the job.

See image: http://forums.sketchucation.com/download/file.php?id=65052