The Naming of Groups (API issues)
-
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
-
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
-
Rich.
I think Fredo recently revealed some thoughts and experiences about this that was quite some intressting read. 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
Best Regards/
Joel -
@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
-
Three names? I only know of two...
Groups are the same as ComponentDefinitions - they both have ComponentDefinitions. It's just that SketchUp applies some special rules to Groups such as automatically making instances unique when you edit them with the native tools.
The instance has a name and the definition has a name. The Outliner will display both:
But unnamed groups will just display "Group" regardless of the definitions actually being named "Group#1", "Group#2", "Group#3" etc
So, with Componentn Instances, they normally don't have an instance name, and you only see the definition name in the Outliner. But if you give it an instance name you will see it - and I often make use of that to ID a set of components in the Outliner.
Groups doesn't expose the definition name in the UI, but otherwise works just like components.
Note that there are some issues in SketchUp when you give a name to a group/component using Entity Info - it appear that SketchUp some times transfer the name to other entities. I'm not 100% sure but it seems that if you type the name to a group and immediately click another group the other group will get the name. But I think it works properly if you click in empty space first before selecting the other group.
-
can you post the file?
to get a handle on it
And have you used the outliner filter?? -
[Please don't double-post on the same topic - these are too similar, I have merged them
]Components & Groups have definitions.
These have names.A Component definition is called something accessible like 'Door#123'.
This can be changed by the user.
It is displayed in 'Entity Info' as Definition-Name: 'Door#123', Name: '' [blank].
And in the Outliner as '<Door#123>'.A Group definition is called something generic like 'Group#123'.
This definition-name can only be changed by the user via the API - it's not accessible in the program.
It is displayed in' Entity Info' as Name: '' [blank].
And in the Outliner as 'Group'.You can 'name' a Component-Instance - e.g. 'MyDoor A' - it is then shown in 'Entity Info' as Definition-Name: 'Door#123': Name: 'MyDoor A'.
And in the Outliner as 'MyDoor A <Door#123>' - showing its 'Name<Definition-Name>'.
definition.name >> 'Door#123'
definition.instances[0].name >> 'MyDoor'You can 'name' a Group - e.g. 'My Group' - it is then shown in 'Entity Info' as 'My Group'
And in the Outliner as 'My Group'.
group.name >> 'My Group'
group.entities.parent.name >> 'Group#123'
[there is no built-in 'group.definition' method - just use the method above...]
So once you get your head around the 'definition-name' and the 'instance/group-name' it's a doddle...
-
I think the 3rd name Rich is referring to might be the title given to each Dynamic Component/Group attribute block in the Dynamic Component Attributes window? Revisions to these titles can be tricky to manage, depending on whether a user wants parity between these titles and other names/definitions. Mainly because the titles aren't automatically updates when a user changes the name in Entity Info (as happens with the Outliner). Things get even messier depending on whether folks use generic "Parent![Attribute]" references when passing parent attributes down to nested components/groups, or whether they use more specific "Boxes![Attribute]" references. Haven't seen very many cases where folks create Dynamic Groups, but it's possible, so... fwiw.
-
Ah! Didn't consider DC's own system.
-
BUT the DC name is NOT the Group's name NOR the Group's definition name.
It an attribute of the DC [which can be a group inside a DC] and which happens to be called 'name', and is displayed in the DC dialog.You can give any object [let's say a group] any number of attribute dictionaries, each containing the key 'name' with some text as its value...
Then you could then write a simple script to find a selected group's details - here as a one-liner for PC users:return unless group=Sketchup.active_model.selection.grep(Sketchup::Group)[0]; puts "Names:"; puts "Group: #{group.name}"; puts "Definition: #{group.entities.parent.name}"; group.attribute_dictionaries.each{|d|d.pairs.each{|k,v|puts "#{d.name}: #{v}" if k.downcase=='name'}if d.length>0}For a 'attributed' group this could potentially produce a long list of 'names' !
So, just be wary of the 'name' of 'name' in the DC - if it were called 'Reference' we would be having this exchange...
-
@richmorin said:
@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
Groups should be unique and not treated as components with multiple instances when freshly copied. This is causing so much trouble for scripts! and probably the source of numerous crashes.
Regarding group names, I think the SU implementation is that the name is just an attribute. The identification is done internally based on Ids of the underlying definitions.
If we wanted that all groups are created with a unique name, then I am afraid that this is a request for the SU team to modify the core.
Of course, a script that will make all name unique can be written, but you would have to run it every time you create a new group.
Fredo
Advertisement