Can a script fire another?
-
the idea is that it could be great to have a toolbar (or menus) with programmable icons
please add the question could a ruby fire a keyboard shortcut!then customisation would become truly powerful (please say yes!)
-
@cadfather said:
the idea is that it could be great to have a toolbar (or menus) with programmable icons
please add the question could a ruby fire a keyboard shortcut!then customisation would become truly powerful (please say yes!)
It would be possible, but of course getting another tool's 'command' is far from straightforward, and with encrypted rbs scripts very very awkward to 'get'.O a PC you coul use 'winscript' within a ruby to mimic key-strokes - so executing a shortcut from a plugin is possible - but IMHO it's no advisable...
-
so there is no way to call a script like we do with the keyboard shortcuts?
sketchup lists all the commands in the shortcuts window - so i thought there may be a way to fire those
-
You misunderstand.
It is possible to read that data and get a list of the users shortcut keys.
On a PC it's then possible to mimic keystrokes using 'winscript' run from within ruby [there are probably MAC equivalents], but I don't recommend doing it...I did write something ages ago to open a group for editing vis ruby, using premade shortcuts, but it is clunky...
-
flatz... i was already dreaming of a complete array of new toolbars
-
Did you look at Jim's custom toolbars and my LaunchUp?
We had thought about (maybe) to combine both their strengths into a toolbar editor (for all Ruby toolbars).
-
@aerilius said:
We had thought about (maybe) to combine both their strengths into a toolbar editor (for all Ruby toolbars).
LauchUp without the text, i.e. just the icons, is already a dynamic toolbar?
so what if 'LU options' showed 'all' with check boxes to make, 'base' toolbar preference list?thinking out loud...
john
-
what? ...friends..don't raise my hopes in vain!
jokes apart, Aerilius LaunchUp is amazing - just not my favourite way to access commands (key and icons)
if i can avoid typing i'm happy..to have a toolbar twice customisable is a sketchup dream - if the technology behind launchup works to this purpose, i'm all for participating in the "grand unified toolbar custom project for sketchup nerds" ..or simply GUTCPFSN
coding wise.. i can only do the menus and toolbars - can make plenty of icons for though
-
LaunchUp is from it's concept almost the opposite of a toolbar creator (I have now setup all my toolbars to be hidden). I want to keep the code and concepts separate, but there's a lot I can re-use for custom toolbars. See with what I come up…
-
......................................................!!!
-
@cadfather said:
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 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.) -
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.
-
@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 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'snew()
constructor.If not explicity set public, then a
call()
method would returnnil
, 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 settrue
.
Ie:
SomeAuthor::Widget.cmd.call()
-
This is a preview of how it could work.
I only need to connect the wires to the same backend that LaunchUp uses…
Oh, and I hope Trimble will not prevent it (as it could be interpreted as violation of unwritten rules). Rather I wish they add theUI::Command.proc
that we have been lobbying for so long. -
WOW!!!
Aerilius, that looks the ******** business!
Edit: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Edit 2: of course let me know if there's anything i can help with.
-
Not gonna lie, that does look the ******** business!
Hope this becomes a reality so I can use it!
Cheers!
-
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. -
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.
Advertisement