Updated parametric.rb ruby script

[john_mcclenahan]

I’ve used the original parametric.rb plugin from the Sketchup team in two of my plugins, SU Draw Parametric Shapes, and Polyhedra (both hosted on the SketchUcation Plugin Store).

It suffered from two drawbacks, which I’m pleased to say have now been fixed by Steve Baumgartner (@slbaumgartner). Many thanks, Steve.

1.Parameter order was not preserved when Editing an already-drawn component, as the parameter key/value pairs were stored in a hash, not an array, and would be returned in an arbitrary order.

2.If I installed both plugins, then I would get duplicate entries in the context menu when right-clicking to edit a drawn shape or polyhedron.

To preserve key/parameter order, each derived class in the calling function now needs to define a new function which passes an array of keys to parametric.rb in the required order. Here’s an example from the Shapes plugin, for a Helix shape:

  def keys
    ['start_radius','end_radius','start_height','end_height','start_angle','rotations','num_segments']
  end

To preserve backward compatibility, the revised parametric.rb implements a default keys method which returns nil , if not overridden by the derived class as in the example above.

I’ve updated both my plugins on SketchUcation to use the revised parametric.rb plugin, which will be installed along with the parent program when you update the plugin.

You need to restart SU after updating the plugin.

Here’s the updated code. Note, if you want to use it yourself, change the Module name to show your own initials and calling program name, to avoid namespace clashes.

parametric.rb (14.4 KB)

[Aerilius]

Thanks!

But best would be if you could create a GitHub repository for it! That makes it easy to find and comment/suggest/merge improvements or even upstream improvements to SketchUp. Of some of the oldest scripts from the earliest days exist multiple versions that have been passed down from mouth to mouth (or copy-paste). Another developer would maybe not find the latest file and add improvements again to an older version.

The thing is, a file attached in a forum will continue to further spread around even after there was a newer version created somewhen in the future.

[john_mcclenahan]

Good idea. There is a version on GitHub already, dating back to my earlier version of SU Shapes which ThomThom helped me post as the first SU Community plugin. I haven’t updated parametric.rb there, and should.

Will try to do that in the next couple of days, if I don’t get time today.

[john_mcclenahan]

Actually, I’ve just looked at old Issues and posts on GitHub about the SU Shapes program there. Most of the issues were never closed.

It seems it isn’t as simple as just having me post an updated version of parametric.rb there.

My version of SU Shapes on SketchUcation plugin store has diverged considerably from the original on GitHub, which was also published (by the SU team, or more probably by Thomas Thomason (@thomthom)) on their behalf before he joined it, after he’d helped me clean up my Shapes code.

There was a discussion too with Dan Rathbun (@DanRathbun) about the complications of having different versions of parametric.rb in different plugins (which I do at the moment, each with a different module name, one for each plugin). And the module name for the version(s) on GitHub don’t start with my initials (JWM) but with Community Extensions, IIRC.

Furthermore, the SU Team didn’t want to have the Helical objects included, since none of them produce solid shapes. So to update the SU Shapes versions there to take advantage of the two improvements in parametric.rb that Steve (@slbaumgartner) has made would require edits to the code for each shape class, which I don’t have the rights to do.

So by pinging @thomthom I hope he can advise how best to publish parametric.rb on the GitHub SU community page(s), or even do it, since I don’t think I have the rights to do anything more than make a pull request - and it’s so long since I did, that I don’t remember how to!

That older version is still on the Extension Warehouse, so that would need to be updated too, and I’m not a Developer for that plugin store. So I couldn’t do that either.

PS. Perhaps I’m conflating two separate issues: updating the SU Shapes program to include and use the revised parametric.rb and just publishing the updated parametric.rb separately in my own right, acknowledging Steve’s contribution (unless things have changed, he doesn’t have a GitHub account himself).

I could just publish it, but will wait to see if the SU Team, ThomThom, or Dan have any comments before doing so. That may not be the best solution for SU Community Extensions.

[tt_su]

Hi John

The “Shapes” extension has been acting as an example on how to make a SketchUp extension with some basic parametre behaviour. Though it’s somewhat dated could use update.

I don’t recall why non-solid was rejected - looking at it now I see nothing in the name of description that should indicate it’s solid only.

The issues with parametric.rb made it a challenge for us to dedicate enough time to maintain this. Key issue I see is if multiple extensions using variations of the old parametrics.rb but still referring to the same dictionary name. https://github.com/SketchUp/sketchup-shapes/blob/master/src/su_shapes/parametric.rb#L112
I think going forward the Shapes extension should be the one that “owns” the original “skpp” dictionary names and derived extensions should use their own name to avoid clashing.

@john_mcclenahan

PS. Perhaps I’m conflating two separate issues: updating the SU Shapes program to include and use the revised parametric.rb

Yes, I think we need to detangle this conversation. parametric.rb as something installed directly into the Plugins folder and shared between extensions are not a good path for developers or users. There is no control over version and not formal API contract that ensure backwards compatibility. Hence my comment above about derived copies should use their own dictionary name and be backed into the extension’s namespace.

As for the Shapes extension - John, we can look into merging you latest changes if you’d like to try that path. Maybe we can add you as a maintainer to give you a git more leeway to manage the project. We could then do some periodic updates at a given interval. (We don’t have to capacity to do this for every small update though.)

Alternatively you could fork the project and manage it from there yourself. Giving your version a new name and upload that yourself to EW. The source code for the extension is MIT licensed - so there’d be no issues there.

[john_mcclenahan]

@tt_su

I don’t recall why non-solid was rejected

As I needed the helical shapes for a model I was working on at the time, I went ahead and added those, and (I think at about the same time) changed from creating a group drawn at the origin, to a component placed at a user-selected pick point.

IIRC it was @DanRathbun who suggested that since these three shapes weren’t solids, they should be excluded from the Community plugin, and they could be made into a separate plugin. I hadn’t the time to separate them, so let the two versions fork.

I fixed a few minor bugs (mainly in the validation of parameters) in the SketchUcation version too, and I don’t think they found their way into the SU EW version either.

THE big change, though, is Steve’s (@slbaumgartner)'s update to parametric.rb with accompanying changes to the Shapes classes to provide a sorted order for the ‘keys’ array,

From my point of view, the simplest thing to do would be just to replace the GitHub and EW plugins by the newest code for both Shapes and parametric.rb from the SketchUcation Plugin store, and to ask you or the SU team to do it, as I don’t have the editing rights for either.

If you want to keep the SU version limited to solid shapes, just delete all the Helical classes, and their menu entries.

And if you want to publish the revised parametric.rb to stand alone, again have you or the SU team publish it separately on GitHub and/or EW, with better version numbering and version control for others then to adopt as they wish.

AFAIK it is fully backward compatible with the older version and a pretty simple and nearly drop-in replacement for it, needing nothing more than a module name change, in parametric ,rb itself, and the addition of the module name in the calling program to reference it.

But I’m not a good enough Ruby programmer to be sure of getting all of this right, I’m afraid, on either GitHub or EW.

I remember when you changed the module naming for the Community SU Shapes plugin, I couldn’t get things to work for some time in my own plugin, as I didn’t understand the implications, nor how to reference it properly from my calling program when adapting Shapes to become the separate but similarly structured Polyhedra plugin (also on both SketchUcation, and the EW). However, Polyhedra isn’t affected by the change in parametric.rb since it has only one parametric parameter - ‘size’. Whether this defines the edge length or the radius of the circumscribed sphere is defined by a separate non-parametric dialogue, So the ‘keys’ can’t get out of order, as there’s only one parametric ‘key’.

I think I’m going to have to pass this one back to you or the SU Team for action, Thomas.

Sorry.

[DanRathbun]

@john_mcclenahan

IIRC it was @DanRathbun who suggested that since these three shapes weren’t solids, they should be excluded from the Community plugin, and they could be made into a separate plugin.

I kinda still do believe this, but at the minimum these 3D Paths should populate a separate submenu.
(Ie, I see them as paths not shapes. That is not to say that they are not a value to modelers.)

[john_mcclenahan]

@DanRathbun

these 3D Paths should populate a separate submenu

That seems sensible to me, perhaps just having a separator before the Helix and other helical shapes?

Or did you mean one Draw submenu for (solid) Shapes, and another for Helical Shapes?

Can’t do it today, but by the weekend I should be able to modify it in the SketchUcation plugin store, and incrementally update the Shapes plugin version number there.

[slbaumgartner]

@john_mcclenahan didn’t mention it, I think, but I also did two other things to parametric.rb: I got rid of the evals that had troubled @tt_su before, and added a check whether the entity right-clicked actually belongs to the module that receives the callback to edit, as opposed to simply having a “skpp” attribute dictionary. His extensions won’t collide with others that use parametric because our version is nested inside his module namespace.

[tt_su]

@john_mcclenahan

From my point of view, the simplest thing to do would be just to replace the GitHub and EW plugins by the newest code for both Shapes and parametric.rb from the SketchUcation Plugin store, and to ask you or the SU team to do it, as I don’t have the editing rights for either.

If you want to keep the SU version limited to solid shapes, just delete all the Helical classes, and their menu entries.

Can you set up a PR for Shapes with your latest version?

@john_mcclenahan

And if you want to publish the revised parametric.rb to stand alone, again have you or the SU team publish it separately on GitHub and/or EW, with better version numbering and version control for others then to adopt as they wish.

Standalone parametrics.rb to be placed directly in the Plugins folder and shared among extensions will only cause problems. (As it already does.) Such shared things would have to be designed to be offering a stable backwards compatible API to even have a chance. But even then, we currently don’t have infrastructure to let extensions declare dependencies and offer a simple installation for users. I’m personally moving away from TT_Lib in my own extensions because while it’s convenient for me as a developer - it’s not the best user experience. And it becomes inconvenient for me since I need to deal with the support.

@john_mcclenahan

I think I’m going to have to pass this one back to you or the SU Team for action, Thomas.

I think we can look at the Shapes extension in isolation. And get that updated with latest improvements.