Can a script fire another?

Dan Rathbun

so there is no way to call a script ...

YEs.. and I have a few dynamic buttons on MY edition of the Ruby Console toolbar, that can re-load a script FILE. This is for development purposes.

Ordinarily.. SketchUp plugin functionality is event driven, and only loaded ONCE.
The days of re-running a linear set of statements (re-loading a rb script file,) EVERY time you want to do some task,.. are over, and very inefficient.

@cadfather said:

... like we do with the keyboard shortcuts?

Keyboard accelerators (aka shortcuts,) do not run a script.
The fire command procs, via their command ID.

The main issue CF is that the API, does not create a getter method to access the proc of SOMEONE ELSE's UI::Command object.

Most of the native tools and such are not a problem, as there is a good set of send action strings (and even more on PC, because the NATIVE command IDs do not change very often, if at all. So we actual DO have a list of command IDs for native tools and application actions.)

OK.. so IF we can make a standard.. AND get coders to agree to register their procs into a "table" (probably a Hash,) then a user customizable toolbar editor is VERY feasible.

But it will ONLY work for coders that FOLLOW the standard.

IN addition.. the API does not give full access to user shortcuts.
Sketchup::get_shortcuts() only returns an array of strings, being the text representation of the keys, and the name of the shortcut,... BUT not the actual command ID that the shortcut fires.

Dan Rathbun

@dan rathbun said:

IN addition.. the API does not give full access to user shortcuts.

I am talking about a collection (be it Hash or whatever.)

The "school of thought" is that shortcuts are USER settings, and Ruby scripts should not be setting or changing what the user wants and has set.

There is a beta plugin called "Crysis" that massively changes user shortcuts to enable a popup "toolpage".
But it has not been received very well. (An the author just cannot understand why,... and we cannot make him understand. He just gets T'ed off when we try.)

CadFather

Thanks Dan - i actually understand what you wrote..

ok, so this standard should really be set by trimble so any developer HAS to follow course.

Dan Rathbun

@cadfather said:

ok, so this standard should really be set by trimble so any developer HAS to follow course.

Well this is a "political" issue.

Some plugin authors.. especially commercial guys.. may not want anyone else to access their command procs in any other way, then via THEIR menu and THEIR toolbar.

They have a right to be possessive to prevent "re-branding" and other "un-niceties".

Authors who do not care, can right now create references to a Proc and a getter method so other could use it. But there is no standard.. so it can be and is done in a number of ways... IE, the identifier can change from author to author.

Now the API could be changed so that proc references are always created.
But there are issues with some Pro-Only plugins that would be defeated (some of them are OEM extensions.)

SO it's not an easy issue.

Dan Rathbun

@dan rathbun said:

@cadfather said:

ok, so this standard should really be set by trimble so any developer HAS to follow course.

Now the API could be changed so that proc references are always created.
But there are issues with some Pro-Only plugins that would be defeated (some of them are OEM extensions.)

I am thinking about a "public" switch, that can only be set when a UI::Command is initialized, via it's new() constructor.

If not explicity set public, then a call() method would return nil, instead of firing the proc.

Example:

@cmd = UI;;Command.new("Widget",true) {
  # this block is converted into the command's proc
}

def cmd()
  @cmd
end

So some other plugin / utility that has a reference, or gets it via:
SomeAuthor::Widget.cmd
can call the proc, and it would execute IF the public flag was set true.
Ie:
SomeAuthor::Widget.cmd.call()

Aerilius

This is a preview of how it could work.
I only need to connect the wires to the same backend that LaunchUp uses…
drag & drop interface
Oh, and I hope Trimble will not prevent it (as it could be interpreted as violation of unwritten rules). Rather I wish they add the UI::Command.proc that we have been lobbying for so long.

CadFather

WOW!!!

Aerilius, that looks the ******** business!

Edit: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Edit 2: of course let me know if there's anything i can help with.

renderiza

Not gonna lie, that does look the ******** business!

Hope this becomes a reality so I can use it!

Cheers!

Box

I'll add my ********business to that. The ability to mix and match would be priceless.
I'd love to be able to select a set of tools and have them all in one box.
Sometimes you only need one button from a toolbar but you have to have the lot.
As an example, throw simple bezier button together with EEBR and Radial bend. Three very useful tools together, little landscape used, you can always go to plugins or tools etc if you need one of the others.

RickW

ToolbarBuilderDemo is now available on Smustard.com for creating custom Ruby toolbars. Pro version to follow, with ability to save and load your toolbars, plus additional features.

CadFather

cool...it'll be interesting to compare the two, if and when Aerilius produces his masterpiece...

Aerilius

Sorry for being late

CadFather

@aerilius said:

Sorry for being late

that's quite alright.. i was taking my time anyway..