Starting a new Ruby Tool Extension

Garry K

One more thing - I too like to test on multiple versions of sketchup with a single plugin install.

I test with SU 7, SU 8, SU 2013, SU 2014, SU 2015 and SU 2106

I create a 2 line ruby file that I name loader.rb - it contains:
require 'sketchup.rb'
require_all('c:/users/public/documents/sketchup')

Then I put my various plugins into the shared folder 'c:/users/public/documents/sketchup' and treat it as the same as the plugins folder for each Sketchup version.

I then run a batch file that prepares and copies all the necessary files into THAT folder.

johnwmcc

Thanks to all. That has probably given me enough to get started. And there is a more recent but still several years-old (copyright 2012) linetool.rb on the Extension Warehouse as part of the SU Examples download. I'll see how I get on using that as a model.

If I can, over coming weeks rather than days, I'll see if I can create a skeleton for more general use. But perhaps that isn't as simple or maybe even as useful as I first thought!

I already use a 'loader.rb' file as suggested above. What I was trying to ask was what the code would look like so that the extension isn't restricted to having its support folder and files in SU's Plugin folder. And I think you have given me something to try instead.

TIG

AND...
There are hundreds of non-encrypted RB files in the SCF PluginStore's various RBZs, which are 'Tools' etc and can offer you valuable insights [aka: 'cribs'] into how certain aspects of SketchUp's Ruby and Tools etc are handled by their authors...
[Of course mine are the best ]

driven

I agree looking at other scripts is a worthwhile experience...

as my tag line says...

john

driven

@johnwmcc said:

... What I was trying to ask was what the code would look like so that the extension isn't restricted to having its support folder and files in SU's Plugin folder.


File.join(File.dirname(__FILE__),  File.basename(__FILE__, ".*"), 'the_file_your_after' )

have it anywhere for any version of ruby...

you'll often see it split so you can use the different bits for other things...

dir = File.dirname(__FILE__)
base =  File.basename(__FILE__, ".*")
file = 'the_file_your_after'
target = File.join(dir, base, file)

john

johnwmcc

Of course, @TIG, you are quite right... and I use several of yours.

Sent from my SM-G935F using Tapatalk

thomthom

I had started last week on some basic tutorial - included how to set up a basic extension. And one for a a basic line tool.

I attached the line tool example - got lots of comments. Let me know what you think.

tut_custom_tool.zip

Garry K

Here's my 2 cents

Good that you show start_operation and commit
I think it is easier to teach when things are a bit more formal so I use () parenthesis for all functions.
Also I prefer to instantiate InputPoint in the initialize
Also you may want to pass things into the tool such as language dictionaries etc.
I think showing how to set up a tool bar is a good idea for a tool
Perhaps even a context menu for editing (right click).


      def initialize()
        @mouse_ip = Sketchup;;InputPoint.new()
      
        path = File.dirname(__FILE__)
        cursor_icon = File.join(path, 'my_cursor.png')
        @cursor_id  = UI.create_cursor(cursor_icon, 0, 32)

        # for VCB parsing - need to know the delimiter
        @delim = ("3,7".to_l rescue false) ? ';' ; ','
      end

      def activate()
        reset_tool(nil)
      end

      def onCancel(reason, view)
        reset_tool(nil)
        view.invalidate()
      end

      def reset_tool(view)
         @mouse_ip.clear()

         if (view)
           view.tooltip = nil
         end
      end

      def onSetCursor()
        UI.set_cursor(@cursor_id)
      end

      def enableVCB?()
        return true
      end    

      def onUserText(text, view)
         # parse a couple of values
      end
    end

    unless file_loaded?(__FILE__)
      # best practice to set this early - especially if a timer is involved
      file_loaded(__FILE__)

      # add toolbar


      # add menu

    end

driven

@garry k said:

...I think showing how to set up a tool bar is a good idea for a tool

If we are discussing best practice for an Extension that provides a tool, than I believe the 'menu' items should be separate from the tool and be used to initialize the tool...

The Extension .rb loads the lang dictionary and the menu loader code and that's all...

the menu code should load the tools logic and it runs...

if never triggered during a session it is not even loaded...

my 2 pence...

john

thomthom

The example focused on writing a tool. Tool are so complex that in an example I didn't want to muddle everything else into it. In the examples I'm writing I was a separate "tutorial" that describe in detail how to structure the folders and register the extension and add a menu.

Toolbars and localization are good separate topic - each deserving their own attention. I had thought I'd put it on GitHub once it was more fleshed out - but maybe I should try to put out the WIP since we already have a topic on this going here.

As for parenthesis - that's a code style and that is something people have to pick for their own. I used explicit parenthesis myself because I was familiar with other languages that always required them. But in Ruby this isn't the norm. I found that it was easier to just use normal convention for the language - as sharing code and adopting example code required less work.
For Ruby code I use the GitHub style guide which seem to be the de-facto standard. IDE's normally base their inspection rules on this and you'll hear a lot of squawking if you use a different style - unless you spend the time to reconfigure the style rules.