SketchUp RUBY API Wishlist [way of coding wishes, please]

NewOne

Move (and rotate) axes from ruby !!! Actually, to be able to access any tool from ruby.

regards!

Matt666

Hi all !
One ruby improvment :

A command autolisp like function !! To have access to all native tools (like said NewOne), and to have possibility to control this tool !
Command autolisp function work like that :
To make a line :

(command "_LINE" "0,0,0" "10,0,0" "")
(command " 'International Name of the tool' " " 'first point' " " 'any point you want' " "")

"" stops the command.
One very intersting thing is you can insert pause that let user doing what he wants !

(command "_LINE" "0,0,0" PAUSE" "")

PAUSE stops process and let user giving a point, in this example.
Another cool thing is an Autocad variable that show if a command (or tool) is active. And you can use it in the code !

(command "_LINE")(while (not (eq (getvar "cmdactive") 0)))(command PAUSE))

(getvar "cmdactive") returns 0 (no active tool) or 1 (one active tool)

tomasz

Selection display bug to be fixed, please.

Jim

Something I have been wanting to do is write a suite of general-purpose Observers based on the built-in ones. Most of the Observers are designed to be attached to a specific entity in a model (or to THE model) - the SelectionObserver, for example is attached to a model's selection collection. It just seems inefficient and error-prone for each plugin author who needs one to implement their own SelectionObserver when a single instance can handle all requests.

So, I guess I'm really proposing a simplified API for using Observers.

The way I see this API working is that a plugin would 'require' the observer file, which would create a single Observer instance. Then the plugin would 'register' methods in the form of blocks (or procs?). In my experiments, I used the Ruby Singleton class to ensure there is ever only one instance created.

Here is how I see the API being used (without getting into the details of the implementation):


# My Plugin
require 'app_observer' # Global AppObserver instance created
def hello(args)
  puts "Hello #{args}"
end
# Register hello() to be called for an onNewModel event
id = AppObserver.instance.register("onNewModel") {|args| hello(args) }
# AppObserver attaches itself when its registry goes from 0 to >0 elements
...
AppObserver.instance.unregister(id) # stop calling hello for onNewModel event
# AppObserver detaches itself when its registry falls to 0 elements.

It really simplifies using Observers, which in turn could allow authors to create better plugins, with more advanced features, in a shorter time. It may also save on resources by having one and only one instance of most of the Observers (confirm?)

(related post)

david.

Jim,

Nice idea. Also, I'm curious if you mixed in the Singleton module to implement your singletons? I've found that I can't require a library module like Singleton unless I point directly to my Ruby installation directories. I realize that this isn't required to implement singletons, but it seems the most simple and consistent.

Jackson

Welcome to SCF Scott, it's great to see your involvement here!

scottlininger

@jim said:

Something I have been wanting to do is write a suite of general-purpose Observers based on the built-in ones.

This is a fantastic idea. Attaching observers reliably to every component instance, for example, is challenging. So a helper script is one approach... another would be to create some uber-observers at the Sketchup level. Obviously, there are potential performance concerns with any of these.

JClements

A standard for displaying script documentation, besides their description, in the menus:

The ruby filename, creator, version level; basically an "about" display for each script. Optional info could be copyright info, contact (email) link, website link, and display of a help file on a local drive.

=============================================

An easier way to organize scripts in a user defined menu (there are scripts that do this now, but I wouldn't call them user friendly)

tomasz

New method for a texture, very useful for exporters.
texture.alpha_channel? -> (true or false)

Whaat

@unknownuser said:

New method for a texture, very useful for exporters.
texture.alpha_channel? -> (true or false)

Ooohhh..that reminds me:

How about a method that samples the texture color on a face?

face.color_at(u,v)->returns a SketchUp::Color object.

Could be used for displacement mapping inside SketchUp for example.

Jim

@david. said:

Jim,

Nice idea. Also, I'm curious if you mixed in the Singleton module to implement your singletons? I've found that I can't require a library module like Singleton unless I point directly to my Ruby installation directories. I realize that this isn't required to implement singletons, but it seems the most simple and consistent.

Hi David,

Yes, I used the singleton class from Ruby. I copied singleton.rb from the Ruby language installation to a 'ruby' folder in my Sketchup/Plugins folder. The Ruby singleton is very easy to use, and was simply the best and fastest solution. I think there are a few other files from the installed Ruby files that I needed also.

morisdov

Hello

Inside SketchUp it works fine but when creating an AVI file with Export -> Animation
the - Sketchup::Pages.add_frame_change_observer - is not firing between frames.

Is there anything i should change or another observer i can use between frames in Export Animation ?

301 Moved Permanently

(www.sketchucation.com)

Thanks

Jim

One of the more important things that could be done using the Ruby API, and which would benefit nearly all users is a unified API for menus and toolbars. I don't mean being able to lock toolbars; I mean the possibility to provide menu and toolbar customization using a "Menu & Toolbar Editor" within SketchUp.

The need is apparent in CadFather's Toolbar plugins; where he creates a collection of scripts and adds toolbar buttons for them. Although these are nice toolbars, they are going to prove difficult to maintain as scripts are updated and obsoleted.

Really, there would need to be some registry that would:

"install" a plugin so that is is not located in the Plugins folder, and so not automatically loaded.
allow un-modified plugins to continue to function.
allow new/modified plugins to create new, or be added to, existing menus, submenus, and toolbars.
handle the creation of menus and toolbars at startup.

The possibilities are fantastic, if you let your mind run wild:

allow menu/toolbars "sets" to be created.
allow plugins to be downloaded as-needed, or used online. (zero install: net_require "progrsssbar.rb")
check new versions of plugins online, and upgrade.

Of course, I do not mean to remove the ability for developers to create their own menu or toolbars. But even if it's just for the numerous scripts that are single-menu, or single-button plugins, this would be an improvement.

(related post)

Matt666

Hi guys !
I wish one day, we would have access to print parameters via ruby... One day...

tomasz

An important wish for ALL exporters, I believe:

a method to read a cropped region in 2point perspective view.
As far as I am aware, currently there is no way to read it!

Please!

tomasz

A Ruby method that will give us a real UVW coordinates of a projected texture, so exporters could use a single, original texture, instead of say 200 small textures of a photo mapped terrain.

chrisglasier

A switch (if it does not exist) to activate a ruby on selection of an entity or entities to allow interaction with a webdialog.

See:
http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=14299

Thanks

Chris

TIG

@chrisglasier said:

A switch (if it does not exist) to activate a ruby on selection of an entity or entities to allow interaction with a webdialog.

See:
http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=14299

Thanks

Chris

Search v7..............

notareal

@unknownuser said:

A Ruby method that will give us a real UVW coordinates of a projected texture, so exporters could use a single, original texture, instead of say 200 small textures of a photo mapped terrain.

Agree!

confitex architure

Hi ScottLininger.
Not realy a ruby way of coding, but almost...
I mentionned it in an another post: It would be so nice to retrieve a variable from a model into a dynamic component's attribute instead of the opposit (right now, if I understand well, it is only possible to "export" and to make a code to fill the DC's attribute).

By the way, I would be very glad if we could learn from your famous animated "sprite" code

Thanks!!!