Offline
@jolran said:
Hope this can help you (although it's related to modifying geometry in groups):
http://sketchucation.com/forums/viewtopic.php?f=180&t=52014&view=unread#p470425
Yes, that was very interesting. Thanks for the pointer (though it didn't make me feel any better about the situation): "It's worse than that — he's dead, Jim!" Sigh.
-r
I'm not sure how many developers read the SketchUp Discussions forum on a regular basis (I don't). So, here's a link to a topic I recently started there, called The Naming of Groups.
The basic questions aren't confined to developers, which is why I posted there, but I'm sure that some folks here will want to discuss API-related issues, etc. So, feel free to respond to either this topic or the original one, as seems appropriate. I have quoted the original post below, for your convenience...
-r
@unknownuser said:
The Naming of Groups is a difficult matter,
It isn't just one of your holiday games;
You may think at first I'm as mad as a hatter
When I tell you, a group must have THREE DIFFERENT NAMES.-- adapted, with apologies, from The Naming Of Cats by T. S. Eliot;
http://famouspoetsandpoems.com/poets/t__s__eliot/poems/15121I've never paid a lot of attention to Groups, but I've been looking into them recently, with the intent of using them as hierarchical levels (along with components) in Model Viewer. I've run into some naming issues that may have obvious (or even standardized) solutions, but if so, I haven't found them. So, I'm asking for some Wise Counsel (TM).
In a hierarchy, it's critical to have unique names for the items at each level. So, for example, most OSes don't allow a directory to have more than one item with the same name (including extension, etc). This uniqueness allows the OS to maintain an unambiguous handle (eg, "full path name") for each directory or file in the tree.
SketchUp's naming policies for components and groups are somewhat at odds with this need. It's quite possible, for example, to have 300 groups or components named "chair", all listed within a given level of the Outliner. Any given chair will have its own position. If the chair is a group, it may even have different attributes than other chairs.
The Outliner has no problem with this. It simply lists all of the chairs, using the same name for each one. There is no way for the user to tell which is which, unless s/he takes the trouble of inventing a unique name for each one. The Outliner is also willing to allow multiple instances of a given component to have the same name. In this case, however, the essential attributes (eg, dimensions) must be identical.
My presumption is that the Outliner uses each component or group's unique ID (ie, Entity.entityID) to keep track of the individuals, but this information is only accessible via the API; the UI doesn't appear to present it. In any case, I can't create unique paths out of non-unique names.
I've thought of several ways to avoid or deal with this ambiguity. The simplest solution would be to qualify each otherwise ambiguous item name with the unique ID (eg, "chair #43583"). Alternatively, I could maintain a human-friendly sequence number (eg, "chair #1").
However, before I do anything of this sort, I'd like to know if I'm simply missing something or if there is an existing Best Practice for handling this issue. Suggestions, anyone?
-r
The Naming of Groups is a difficult matter,
It isn't just one of your holiday games;
You may think at first I'm as mad as a hatter
When I tell you, a group must have THREE DIFFERENT NAMES.
-- adapted, with apologies, from The Naming Of Cats by T. S. Eliot;
http://famouspoetsandpoems.com/poets/t__s__eliot/poems/15121
I've never paid a lot of attention to Groups, but I've been looking into them recently, with the intent of using them as hierarchical levels (along with components) in Model Viewer. I've run into some naming issues that may have obvious (or even standardized) solutions, but if so, I haven't found them. So, I'm asking for some Wise Counsel (TM).
In a hierarchy, it's critical to have unique names for the items at each level. So, for example, most OSes don't allow a directory to have more than one item with the same name (including extension, etc). This uniqueness allows the OS to maintain an unambiguous handle (eg, "full path name") for each directory or file in the tree.
SketchUp's naming policies for components and groups are somewhat at odds with this need. It's quite possible, for example, to have 300 groups or components named "chair", all listed within a given level of the Outliner. Any given chair will have its own position. If the chair is a group, it may even have different attributes than other chairs.
The Outliner has no problem with this. It simply lists all of the chairs, using the same name for each one. There is no way for the user to tell which is which, unless s/he takes the trouble of inventing a unique name for each one. The Outliner is also willing to allow multiple instances of a given component to have the same name. In this case, however, the essential attributes (eg, dimensions) must be identical.
My presumption is that the Outliner uses each component or group's unique ID (ie, Entity.entityID) to keep track of the individuals, but this information is only accessible via the API; the UI doesn't appear to present it. In any case, I can't create unique paths out of non-unique names.
I've thought of several ways to avoid or deal with this ambiguity. The simplest solution would be to qualify each otherwise ambiguous item name with the unique ID (eg, "chair #43583"). Alternatively, I could maintain a human-friendly sequence number (eg, "chair #1").
However, before I do anything of this sort, I'd like to know if I'm simply missing something or if there is an existing Best Practice for handling this issue. Suggestions, anyone?
-r
Thanks, all, that gives me quite a bit to chew on.
-r
@jolran said:
I think it might be difficult for anyone to help you if you don't post some code.
(having a little hard time following your post)Sounds like the instances failed being unique ?
Problem is, this code is in the middle of a few thousand lines of framework code.
However, I'll think about how I might extract a cut-down example.
@jolran said:
OT: what happened to your excellent post on your blog
regarding dynamic component scripting explorations?
I cannot find it anymore. It was most intresting.
I don't recall writing a blog entry, but I have several pages in my wiki on the topic.
Please take a look at http://wiki.cfcl.com/bin/view/SketchUp/Cookbook/DA
-r
Executive Summary
I need some help in traversing the Model, because I'm getting some
results that I don't understand.
Background
My PF_Model class does a recursive treewalk through SketchUp's Model API,
harvesting information on component definitions and instances, etc. The
result is a data structure that I can index into to find components, etc.
The shipping version of Product Connect pays no attention to the "visible?"
status of either a component or the layer it resides in. This violates the
Principle of Least Astonishment for modelers, who expect invisible portions
of the current Model to be ignored pretty universally.
So, I'm trying to add some code that will cause PF_Model to ignore anything
within invisible component instances (whether hidden explicitly or residing
on a hidden layer). However, in working on this, I got confusing results.
Test Setup
I have two Models, each of which contains three instances of a KraftMaid
"Base Single Door" cabinet. In each Model:
In one Model (KMc_s), three cabinet instances share the same definition.
That is, I simply copied the cabinet and pasted it twice, then hid one
copy and put the other on a hidden layer.
In the other Model (KMc_u), each cabinet instance has a unique definition.
That is, I did a Make Unique on each copied cabinet before hiding it, etc.
Problem
I'm seeing quite different behavior in the two Models and I'm not quite sure
what is going on. The KMc_s (shared) Model gives me the following results:
It finds three entities of type ComponentInstance (ie, instances
of the cabinet), only one of which is visible.
Looking in the cabinet component definition's entities (cd.entities)
for objects of type ComponentInstance, it finds one visible instance
of the drawer sub-component.
The KMc_u (unique) Model, in contrast, gives me the following results:
Analysis
I suspect that there's a better way to traverse the model, if only because
I shouldn't be finding three instances of the drawer sub-component in each
unique instance of the cabinet. Suggestions?
Failing that, I'd like to know why I'm seeing three visible instances of
the drawer and (more to the point) how to tell them apart, etc.
@dan rathbun said:
Sorry for MY confusion, Rich.
No problem! Catching Dan Rathbun in an error is quite a triumph.
More generally, I'm quite sure that my pages have both errors and omissions; I just don't know what they are. If you (or anyone else) can tell me about problems, I'd be most pleased.
-r
@dan rathbun said:
They NEVER WERE allowed in
{...}literals to separate a key from a value, BUT ARE required to separate key/value pairs from one another.
Ruby 1.8.7 (on Mac OS X Snow Leopard) accepts commas as key/value separators:
$ irb --simple-prompt
>> {1,2,3,4}
=> {1=>2, 3=>4}
>> RUBY_VERSION
=> "1.8.7"
The SketchUp team says that upgrading the version of Ruby will be a strong priority for "SketchUp 2013". The current version of Ruby (outside of SketchUp) is 1.9.3, and 2.0.0 is scheduled for release in early 2013. However, moving to either of these versions would break large numbers of plugins.
My hope is that SketchUp 2013 will contain Ruby 1.8.7, with a substantially complete copy of the Standard Library. Ruby 1.8.7 introduces a number of 1.9's features, but it is (mostly) backward compatible with 1.8.6. So, we'd have a year or so to try things out, develop and implement migration strategies, etc.
In any case, plugin developers would be well advised to start learning about the changes in Ruby 1.9, thinking about how to create plugins that will work in either 1.8 and 1.9, etc. In support of this, I have created a couple of web pages that I hope will be useful. Comments and suggestions are earnestly solicited...
http://wiki.cfcl.com/bin/view/SketchUp/Cookbook/RE_Migration - Ruby Migration
http://wiki.cfcl.com/bin/view/SketchUp/Cookbook/RE_19_Changes - Ruby 1.9 Changes
-r
Experimentation indicates that function arguments are passed to the Ruby method as an array of strings. So, it seems like the Ruby method should be performing coercion on the input values. (eg, a[0].to_f). Am I missing something?
-r