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

[Dan Rathbun]

@jim said:

@kwalkerman said:

..., should also be able to retain the active layer for each page.

I like this idea, particularly useful when adding text to Scenes. It seems quite possible using an Observer.

But when you add text to Scenes (Pages,) are you drawing to the model, or drawing to the View ??

If it's the View, then the active layer does not matter.

The active layer is a property of the model. A Scene (Page,) is a View mechanism, which does not "have" layers; it only 'remembers' which of the model's layers to hide or show. A layer also has "new page behaviour" which it can tell new Scenes (Pages,) how to 'remember' their visibilty.

I can see some problems for other scripts, if the active layer was automatically changed when a Scene changed. There would need to be some kind of toggle to turn the "auto" feature on and off.
In addition, their would need to be scoping. What if an Observer was to be triggered while this "auto layer" feature was on? Outside the current script (or scope,) the Observer may want to "see" or "use" another layer as the active one.

It also occurs to me, that we are supposed to always be drawing primitives on "Layer 0", but still some modelers want to draw on other layers (construction lines especially.)

Anyway.. we'd need to consider this carefully. It could be a disaster.

[Dan Rathbun]

@kwalkerman said:

Seconded on the Layers usability, also, it would be great to be able to do:

Layers.active_layer

That can already be done:
Sketchup.active_model.active_layer
.. as it's a property of the model (Sketchup::Model class.)

see API: Model.active_layer

@kwalkerman said:

Layers[layer] = active

Will not work because there is no .= method defined for the Sketchup::Layer class. (You'd just be calling Ruby's internal hardcoded refererence assignment operator, which could set the layer reference on the left of the operator, to any kind of Ruby object. A bad idea, if it doesn't immediately cause an exception.)
This why the .new constructor is "hidden" (or made private,) and we create layers thru the collection class' .add method.

Sketchup.active_model.active_layer=layers['mylayername']
.. again, a property of the model (Sketchup::Model class.)

see API: Model.active_layer=

---

You CAN get a SKP DOM object's parent by using the .parent method. The model is the layer collection's parent, in the SKP doucment heirarchy. Where layers is the model's Sketchup::Layers class instance:
this_layer = layers.parent.active_layer

But, since each model instance, has an instance of a Sketchup::Layers class object, you'd think it (the Layers collection,) should also know which one of it's elements was active.
A simple Ruby patch for the Layers class:

class Sketchup;;Layers
  unless method_defined?('active')
    def active
      self.parent.active_layer
    end # def active
  end
  unless method_defined?('current')
    alias_method('current','active')
  end
  unless method_defined?('active=')
    def active=(arg)
      if arg.class==String || arg.kind_of?Integer
        self.parent.active_layer=self[arg]
      elsif arg.class==Sketchup;;Layer
        self.parent.active_layer=arg
      else
        raise(TypeError,'Sketchup;;Layer, String, or Integer expected.')
      end
    end # def active=
  end
  unless method_defined?('current=')
    alias_method('current=','active=')
  end
end # class extension

%(#4000BF)[**EDIT:

• added aliases* fixed method defintion tests**Note: The reason I do not call]Sketchup.active_model.active_layer (in the patch,) is to accomodate multi-model environment on the Mac, where the active model may not be the one a script is working on.

---

ADD: This can be extended to the Sketchup::Layerclass, so that a layer can return (boolean) whether it is the active layer or not.

class Sketchup;;Layer
  unless method_defined?('active?')
    def active?
      # .equal? returns true ONLY if receiver and arg have same object_id
      self.equal?( self.parent.parent.active_layer )
    end # def active?
  end
  unless method_defined?('current?')
    alias_method('current?','active?')
  end
  #
  unless public_methods(false).include?('eql?')
    # only override if it hasn't yet been redefined
    def eql?(arg)
      if arg.class==Sketchup;;Layer
        # we shall ignore the name attribute
        # use the == override to include name in test
        # use <=> to test only the names (match returns 0)
        same = true
        return (same = (self.page_behavior==arg.page_behavior)) if (not same)
        return (same = (self.visible?==arg.visible?)) if (not same)
        return same
      else
        raise(TypeError,'Sketchup;;Layer expected.')
      end
    end # override eql?
  end
  #
end # class extension

[TommyK]

I don't know if this thread is still checked by the Sketchup team, but I have one ruby request:

• be able to set selection colour per entity, including bounding box color.

It would allow different kinds of entities to be shown as such.

[Rich O Brien]

That's a very old feature request.

I think it was back at v7 I remember seeing members ask for groups and components to be different colours.

I love it to happen. Sorely needed in such a visual program.

[AdamB]

Pretty, but whats the use case?

[slbaumgartner]

@pout said:

does anyone know if any of the remarks here will be taken into consideration in a new version?

The SketchUp development team are famous for marching to their own inscrutable set of priorities, so only they know for sure. But this topic was started by a member of the team, so it is at least as good a place as any for sketchUcation members to post suggestions.

[thomthom]

We're watching.

Since the Trimble acquisition a good number of have been addressed. That despite the fact that we've only had short dev cycles so far. Takes time to shift things around. But we're ramping up.

[tt_su]

I used the wrong - hat... So for the sake of making it right - with my Trimble hat: Yes we are watching.

[TommyK]

@adamb said:

Pretty, but whats the use case?

If people wanted to distinguish some component types from others, for example. Or maybe a plugin could show a graphical overview of all the objects in a model to reflect some attribute, or something?

I have a plugin I want to create that uses 'external components'. To distinguish these from normal components for the user, having a different highlight colour would really help. More info on my thread: http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=59961

[tt_su]

@tommyk said:

@adamb said:

Pretty, but whats the use case?

If people wanted to distinguish some component types from others, for example. Or maybe a plugin could show a graphical overview of all the objects in a model to reflect some attribute, or something?

You could do this with a custom Ruby Tool with the current API though. That is unless you want to display the graphical overview all time time.

[TommyK]

@tt_su said:

@tommyk said:

@adamb said:

Pretty, but whats the use case?

If people wanted to distinguish some component types from others, for example. Or maybe a plugin could show a graphical overview of all the objects in a model to reflect some attribute, or something?

You could do this with a custom Ruby Tool with the current API though. That is unless you want to display the graphical overview all time time.

Yes, with a custom Ruby Tool. I would like to be able to change the highlight colour when the standard selection tool is used, and I believe there is no way to do this. Would you suggest that I script an alternative selection tool to mimic the native tool and add the additional functionality?

Perhaps the Sketchup team would find that the change to the API in this way would be too much of an intrusion to Sketchup's standard tools?

[tt_su]

@tommyk said:

Yes, with a custom Ruby Tool. I would like to be able to change the highlight colour when the standard selection tool is used, and I believe there is no way to do this. Would you suggest that I script an alternative selection tool to mimic the native tool and add the additional functionality?

For the immediate solution with the current Ruby API that would be one way to do it. Though implementing the box selection is a challenge via Ruby - at least without performance impact of the tool.

@tommyk said:

Perhaps the Sketchup team would find that the change to the API in this way would be too much of an intrusion to Sketchup's standard tools?

It would be a concern if there was multiple extensions that modified the selection colour of objects. Which extension would get the last say? And how easy would it be for the user to read the selection if the selection color changed?
Having said that, we've had a couple of requests like this. If you would be able to mock up a real use case, a mock screenshot I can add that to a feature request in our bugtracker.
I personally think it would be nice to have some generic way to draw additional graphic to the screen to display meta data etc. Not just changing selection colour.

[CAUL]

It would be nice if you could retrieve a face from Geom::PolygonMesh. For example:

` ent = Sketchup.active_model.entities

ps = [[0, 0, 0], [0, 10, 0], [10, 10, 0]]
mesh = Geom::PolygonMesh.new
ps.each { |p| mesh.add_point p }
ind = mesh.add_polygon ps
ent.add_group.entities.fill_from_mesh mesh

WISH

f = mesh.get_face ind
############`

If you want to make a lot of manipulations on a complex piece of geometry, it is often an order of magnitude faster to recreate the manipulated geometry from scratch using fill_from_mesh rather than operating on the existing geometry using add/remove face. However, you often want to associate faces in the old geometry with corresponding faces in the new mesh geometry in order to copy over materials and so on, and this is where mesh.get_face would save a lot of time.

[eneroth3]

Isn't it already possible to just change the highlight color in the rendering options? It could be done from a selection observer and depend on what's currentply selected. Only supports one color at a time though.

[tt_su]

@caul said:

It would be nice if you could retrieve a face from Geom::PolygonMesh. For example:

+1 !

[jolran]

+1

But also ability to remove polygons. If I'm not misstaken one can only add polygons(?).
(This was under discussion before)

It would be convienient to use polygonmesh as container at an early stage. Rather as a last step before becoming Sketchup geometry..

Transforms are ~3 times faster (due to indexing?) than transforming required n_points directly as well. Although that can be simulated with a Class.

[TommyK]

@tt_su said:

@tommyk said:

Perhaps the Sketchup team would find that the change to the API in this way would be too much of an intrusion to Sketchup's standard tools?

It would be a concern if there was multiple extensions that modified the selection colour of objects. Which extension would get the last say? And how easy would it be for the user to read the selection if the selection color changed?

I've been mulling this question over these last few days, and I think the solution might be to confine Ruby plugins that manipulate the presentation of a model to a specific style. I haven't formulated exactly how this would work yet, but it makes sense to separate the manipulation of geometry from the presentation of geometry in this way. Would involve extending the Style entity API I expect. What is exciting about this approach is that Ruby can get stuck in doing some special things with the presentation of the model. Eg:

• change line thicknesses for different components (useful for presenting depths of items maybe?)
• Color lines by layer (useful for people working with complex models, and want to retain materials on faces)

This approach makes sense for me, although I am well aware how much more I am asking for compared to my original request! Not to mention compatibility with LayOut.

@tt_su said:

Having said that, we've had a couple of requests like this. If you would be able to mock up a real use case, a mock screenshot I can add that to a feature request in our bugtracker.
I personally think it would be nice to have some generic way to draw additional graphic to the screen to display meta data etc. Not just changing selection colour.

I will mull over the question some more, and get back to you. And yes, additional graphic on the screen would be very handy, and would certainly improve my productivity in certain areas.

@eneroth3 said:

Isn't it already possible to just change the highlight color in the rendering options? It could be done from a selection observer and depend on what's currentply selected. Only supports one color at a time though.

I did NOT think of that! For my purposes, this may do the trick. Thanks!

[tt_su]

@tommyk said:

I did NOT think of that! For my purposes, this may do the trick. Thanks!

Beware that users might not like that extensions arbitrary change the settings of the style they have set up.

[TommyK]

One wish:
Model.active_path= (Array of groups/instances like in existing method: active_path)

I haven't found a way to change the context (path) elsewhere, at least. I would like it in my case, as I use Ruby to reload a Component Definition. When the user is at the path within a Component that is deleted in the script, when the script executes, it just looks rubbish.

Second wish:
ComponentDefinition.path= (String representing path)
Currently, the only way to affect the definition.path of a ComponentDefinition is to use DefinitionsList.load (which loads a new component completely, and isn't completely reliable)

[TommyK]

@tt_su said:

@tommyk said:

I did NOT think of that! For my purposes, this may do the trick. Thanks!

Beware that users might not like that extensions arbitrary change the settings of the style they have set up.

I think the sensible way of getting around this is setting up a new style with the extension. You would then only implement the style changes if the selected style is the extensions style with Styles.active_style.