Request: Command line input plugin

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.