Request: Command line input plugin

EarthMover

In my opinion, it's kind of like taking the motor out of a car and pulling it with a horse....but I totally understand how hard it is to reverse old habits. As in preferring keyboard shortcuts for navigation instead of the mouse.

The closest thing to a command line that is built in, is the Ruby Console. You can call any script from there, but I don't believe you can activate native tools. To find out what command calls a given script, open it with Notepad and look for the line, model.start_operation - followed by parenthesis and quotes. Within the quotes is the command needed to call the script from the Console. It requires typing the full name without deviation. Shortcuts become faster as you need only push a single letter.

Aerilius

You could for example add an empty text file with *.rb extension into the Plugins folder (e.g. "my_commands.rb"), where you insert your preferred commands to abbreviate the original ruby commands:

def p
  Sketchup.send_action("pushpull;")
end

or

def bend
  Sketchup.active_model.select_tool Clf_shape_bender.new
end

with commands from this list or commands that you find inside other plugins (as EarthMover wrote). Then you can use your commands on the ruby console.

@earthmover said:

model.start_operation [...] Within the quotes is the command needed to call the script from the Console.
I could be wrong but I think start_operation just contains the name how it is displayed in the undo/redo stack, but it's not an executable command. The command can often be found by searching for "add_item", it's in the curly brackets after that.

Dan Rathbun

@aerilius said:

You could for example add an empty text file with *.rb extension into the Plugins folder (e.g. "my_commands.rb"), where you insert your preferred commands to abbreviate the original ruby commands:

def p
>   Sketchup.send_action("pushpull;")
> end

That example overrides the global method p(), and can break plugins that use it.
(ALWAYS check the methods in module Kernel, and class Object, before you choose a method name, BUT ....
PLEASE... don't define methods in the global ObjectSpace... they propagate into all classes and modules.)

@aerilius said:

with commands from this list or commands that you find inside other plugins (as EarthMover wrote). Then you can use your commands on the ruby console.

@earthmover said:

model.start_operation [...] Within the quotes is the command needed to call the script from the Console.
I could be wrong but I think start_operation just contains the name how it is displayed in the undo/redo stack, but it's not an executable command. The command can often be found by searching for "add_item", it's in the curly brackets after that.

Yes correct, on the start_operation() text, it's only menu text, and a coincidence (or certain author's quirk,) that it's the same as a command.

TIG

I fail to see how typing in letters+enter at the Ruby Console [or some other command-line GU Interface] is an improvement of a simple shortcut? Even with modifier keys it's little more than a keystroke away...
Pressing L is quicker that getting focus on the window by picking it and typing L+enter ???
And a lot faster that typing 'Line' or 'linetool' or say 'Q.l'/'Q.line' if you defined a 'Q' short-named module to protect things etc
I recommend you learn to use shortcuts... which can be set very similar to ACAD, but just avoid the need for a closing space or return keystroke - SUp's L v. L+space or L+enter for ACAD OR key+modifier[s] v. letter+letter+space etc for lesser used tools...

Jim

@tig said:

I fail to see how typing in letters+enter at the Ruby Console [or some other command-line GU Interface] is an improvement of a simple shortcut?

It isn't an improvement over a shortcut, but you can't have a shortcut for every command you use (or at least it doesn't work for me workflow.) Aerilius' LaunchUp is a great concept. After playing with it, I think it can fill a niche somewhere between a shortcut (most efficient) and a menu (least efficient) for efficiently selecting commands; particularly for less frequently used commands, or commands that conflict with already taken shortcuts.

thomthom

I got a concept code snippet where I subclass the UI, Sketchup::Menu and Sketchup::Toolbar class - intercepting the UI elements so I get all the data and blocks/procs. It allows me to traverse the whole menu tree, all ruby toolbars.
I had a concept pretty much identical to what the OP describes in mind.

Jim

Are you sub-classing, or aliasing and redefining the class methods?

thomthom

@jim said:

or aliasing and redefining the class methods?

You are correct.

Dan Rathbun

@thomthom said:

@jim said:

or aliasing and redefining the class methods?

You are correct.

I just hope that my version doesn't conflict.. ie: the constructor chain would not be broken, ...and visa versa.

thomthom

@dan rathbun said:

@thomthom said:

@jim said:

or aliasing and redefining the class methods?

You are correct.

I just hope that my version doesn't conflict.. ie: the constructor chain would not be broken, ...and visa versa.

My intent was to just insert an intercepting hook - without further disrupting the objects. Just to collect the data that SketchUp doesn't expose.
However, I'm far away from releasing it, as it would need lots more work, error catching and testing. Not sure if it ever will be released. Depends if it can be made without interfering - as meddling with base classes is something I generally prefer to stay away from. It's been mainly an proof of concept.

fredo6

It is relatively easy to catch all menu text and proc (via aliasing #add_item).

It seems impossible to catch the proc for the UI::Command class. The proc argument is actually only passed in the .new construction. But very strangely, UI::Command does not seem to have a regular initialize constructor method like all Ruby classes.

For instance, in the following code, the method initialize will NEVER be called


class UI;;Command
   def initialize
       puts "Fake command initialize"
   end
end

UI;;Command.new
Error; #<ArgumentError; (eval);156;in `new'; wrong number of arguments (0 for 1)>
(eval);156
(eval);156

This may explain why there has been problem with UI::Commands (the grey out menu issue), because if there is no constructor, there is no garbage too!

Fredo

thomthom

@unknownuser said:

It seems impossible to catch the proc for the UI::Command class. The proc argument is actually only passed in the .new construction. But very strangely, UI::Command does not seem to have a regular initialize constructor method like all Ruby classes.

It's possible. I can send you the snippet if you want.

fredo6

@thomthom said:

It's possible. I can send you the snippet if you want.

I just realized that UI::Command is a kind of fake class object factory. new is simply a class method, not an instance constructor (therefore there is no initialize method in that class).

Then, it is simple to trap both menus and commands


class Sketchup;;Menu
   alias_method ;add_item_orig6, ;add_item
   def add_item(text, &proc)
      MyModule.register_menu(self, text, proc)
      add_item_orig6(text) { proc.call }
   end
end	

class UI;;Command
   class << self
      alias_method ;new_orig6, ;new
   end	
   def self.new(text, &proc)
      cmd = new_orig6(text) { proc.call }
      MyModule.register_menu(cmd, text, proc)
      cmd
   end
end

Assuming you register the command and menu object, text and proc via your own method MyModule.register_menu.

Fredo

thomthom

<span class="syntaxdefault"><br />class </span><span class="syntaxkeyword"><<</span><span class="syntaxdefault"> UI</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Command<br />  <br />  alias </span><span class="syntaxkeyword">;</span><span class="syntaxdefault">tt_old_new </span><span class="syntaxkeyword">;new<br /></span><span class="syntaxdefault">  private </span><span class="syntaxkeyword">;</span><span class="syntaxdefault">tt_old_new<br /><br />  </span><span class="syntaxcomment"># @since 0.1.0<br /></span><span class="syntaxdefault">  def new</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">*</span><span class="syntaxdefault">args</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">&</span><span class="syntaxdefault">block </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    obj </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> tt_old_new</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">*</span><span class="syntaxdefault">args</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">&</span><span class="syntaxdefault">block </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    obj</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">send</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">;</span><span class="syntaxdefault">proc</span><span class="syntaxkeyword">=,</span><span class="syntaxdefault"> block </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    obj<br />  end<br />  <br />end </span><span class="syntaxcomment"># class << UI;;Command<br /><br /><br /></span><span class="syntaxdefault">class UI</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Command <br />  <br />  </span><span class="syntaxcomment"># @since 0.1.0<br /></span><span class="syntaxdefault">  attr_reader</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">;</span><span class="syntaxdefault">proc </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">  <br />  </span><span class="syntaxcomment"># @param [Proc] value<br /></span><span class="syntaxdefault">  </span><span class="syntaxcomment">#<br /></span><span class="syntaxdefault">  </span><span class="syntaxcomment"># @return [Proc]<br /></span><span class="syntaxdefault">  </span><span class="syntaxcomment"># @since 0.1.0<br /></span><span class="syntaxdefault">  def proc</span><span class="syntaxkeyword">=(</span><span class="syntaxdefault"> value </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">proc </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> value<br />  end<br />  protected </span><span class="syntaxkeyword">;</span><span class="syntaxdefault">proc</span><span class="syntaxkeyword">=<br /></span><span class="syntaxdefault">  <br />end </span><span class="syntaxcomment"># class UI;;Command <br /></span><span class="syntaxdefault"> </span>

Dan Rathbun

I don't think I like overriding the inherited proc() method that comes down from Kernel (thru Object.)

We already have naming convention established in that class, ie set_validation_proc

I would suggest for setter, instead:
set_proc(&block) or set_command_proc(&block)

the getter:
get_proc(&block) or get_command_proc(&block)

and the getter for the validation proc:
get_validation_proc

thomthom

Good point Dan. I've not checked such conflicts yet and one of the reasons I'd not released the code before.

Jim

So what's going to happen when you guys start aliasing each other's aliased methods?

thomthom

Nuffin? Just a chain of calls?

Jim

@thomthom said:

Nuffin? Just a chain of calls?

Maybe. I don't know, I'm asking.