[Plugin] Material_Maintenance v2.2 - 2013-01-13

[Tpdart]

It may be me, but I've put the .rbz in the plugins folder, restarted SU but I cannot find the command or interface. Any thoughts?

Thanks!

[Gaieus]

You do not use an RBZ file like that. Please, read this tutorial on installing plugins:
http://sketchucation.com/resources/tutorials/37-beginner/108-installing-sketchup-plugins

[Tpdart]

DOH!
I didn't install the extension- once I PROPERLY followed the instructions it looks great I can't wait to try it out on an inherited complex model with many similar materials.

[cmd]

@myhand said:

Bug fix version V2.1.1 released.

... CMD this should fix your problem also as the trace code that had the bug in is also now removed.

Myhand,

Good stuff! no more errors!

.... but I am not getting material thumbnails nor am I getting component images to display.

Is this due to the change for mac?

---

[TIG]

@cmd
If you write this in the Ruby Console ENV['TMPDIR'] + <enter> it gives the path to your 'temp' folder.
In that folder ought to be a subfolder named 'material_maintenance' and in that the xxx.png material thumbnails and xxx.comp.png component thumbnails ? They might have weird looking 'id' type names...
The subfolder is emptied when the tool runs, or it's made if it is missing.
It could be that the files are getting made but some enduring issue in the html/js on MAC is preventing them displaying ??
Can you confirm if the subfolder/files exist...

[Myhand]

@cmd said:

Myhand,

Good stuff! no more errors!

.... but I am not getting material thumbnails nor am I getting component images to display.

Is this due to the change for mac?

I suspect it can be to do with the temp folder location on your MAC. I save the thumbs in a folder I create within the system temp folder. I use a technique (from ThomThom's very good article on materials http://www.thomthom.net/thoughts/2012/03/the-secrets-of-sketchups-materials/)
to "guess" the temp folder.

temp_path = File.expand_path( ENV['TMPDIR'] || ENV['TMP'] || ENV['TEMP'] )

It might be that this does not work on your system and we might have to add some options to the list.

driven, did you see the thumbs on your system?

[TIG]

The ENV['TMPDIR'] should work on MAC, with the other two for PCs.
CMD needs to go look see if the subfolder/thumbnails are getting made...
If they aren't there's an issue with this bit; if they are the issue is with the html/js end ?

[thomthom]

I have experienced some OSX user that didn't have the environment set up correctly - there was no environment temp variable defined at all. That was a once-time thing though.

[TIG]

OK ... then
ENV.sort.each{|e|p e};p
will list everything available...

[Oxer]

I have the same problem like cmd, the material thumbnails don't appear, I work on Mac OSX.
Other question, is it possible translate the plugin to another language?
Thanks Myhand !!

[Myhand]

@oxer said:

I have the same problem like cmd, the material thumbnails don't appear, I work on Mac OSX.

Can you please follow TIG's instructions below and let us know the results?

@tig said:

@cmd
If you write this in the Ruby Console ENV['TMPDIR'] + <enter> it gives the path to your 'temp' folder.
In that folder ought to be a subfolder named 'material_maintenance' and in that the xxx.png material thumbnails and xxx.comp.png component thumbnails ? They might have weird looking 'id' type names...
The subfolder is emptied when the tool runs, or it's made if it is missing.
It could be that the files are getting made but some enduring issue in the html/js on MAC is preventing them displaying ??
Can you confirm if the subfolder/files exist...

Can you also please run

ENV.sort.each{|e|p e};p

and attach the console output.

[cmd]

@myhand said:

@tig said:

Can you confirm if the subfolder/files exist...

Myhand & TIG

Yes... the folders and image files do exist.

CMD

---

[cmd]

@unknownuser said:

Can you also please run

ENV.sort.each{|e|p e};p

and attach the console output.

---

[TIG]

So the folder/subfolder is OK and the images exist.

The image naming seems unduly convoluted, as it's adding some special characters etc...
Why not use each material.display_name [with some replacement of characters like \ / : * ? " < > | etc] linked to a hash of the display-name containing its 'id' ?
The thumbnail-images names match the 'display-names' ?

[Myhand]

@tig said:

So the folder/subfolder is OK and the images exist.

The image naming seems unduly convoluted, as it's adding some special characters etc...
Why not use each material.display_name [with some replacement of characters like \ / : * ? " < > | etc] linked to a hash of the display-name containing its 'id' ?
The thumbnail-images names match the 'display-names' ?

This is sort of what I have done. i.e.

display_name + "_" + object_id + ".png"

with invalid windows file name characters replaced with the ¶ character. I know this character caused us problems in the marshaling on OSX, but forgot to remove it here. I will do so in the next patch.

I do not think this is the problem though as some of the .png files do not have this character in the name...

I will add some trace code (and remove the ¶ character) if you do not mind testing again CMD.

[TIG]

Why no just remove the miscreant character OR use an _ ?

[Oxer]

The same like cmd, the folders and image files do exist.

ENV.sort.each{|e|p e};p

[Myhand]

@tig said:

Why no just remove the miscreant character OR use an _ ?

Three reasons (none valid anymore)

• I wanted descriptive file names (help with debugging)
• I wanted to be clear which chars I replaced (helped with debugging)
• I also have an OCD nerve and in theory by just deleting or replacing with a "ordinary" character could clash two similarly names materials that only differed in special characters (and yes it could still happen if each string have the same number of special characters all in the same positions but different characters or if someone actually used the ¶) but I felt the chances were sufficiently small.

I will probably go for using object_id as it will be exact(which I did not know existed when I wrote this part if the code initially).

[TIG]

You could make a ruby hash of each material 'display-name'/'id' [rather than it's Sketchup name which will involve [], <> etc if it has been 'imported' etc; this 'display-name' is used in the dialog, and it is then linked to the material's 'id' in the hash. That 'id' is then used for the temp thumbnail png file-name. They are both already unique.

The same applies to the component-thumbnail etc.

You can then use the linked name/id to find the material/defn / id, to associate the right png with the material/defn etc...

[Myhand]

@tig said:

You could make a ruby hash of each material 'display-name'/'id' [rather than it's Sketchup name which will involve [], <> etc if it has been 'imported' etc; this 'display-name' is used in the dialog, and it is then linked to the material's 'id' in the hash. That 'id' is then used for the temp thumbnail png file-name. They are both already unique.

The same applies to the component-thumbnail etc.

You can then use the linked name/id to find the material/defn / id, to associate the right png with the material/defn etc...

Is there a reason I not just use the the material's object_id.to_s() as key and also as thumbnail file name etc. It seems unnecessary to concatenate with display_name and then hash, when object_id should be unique within one session...?