New Material Methods! (With bugs :( )

[Dan Rathbun]

@tig said:

@dan rathbun said:

SO TIG you may wish to update your extension then to alias the method names write_thumbnail() and remove() ??

I could - trust Google not to copy my naming conventions!

They could be following the conventions they have established already in the API .. although they didn't in this case (which really irks me to no end.. a quick check of the API methods index is all it takes.. before 'inventing' a new method..)

All the other thumbnail methods use " save_thumbnail()"
" write" was used for images, textures, and IO operations, such as defaults to plist or registry.

" remove()" was used when you 'dettached' an item from something else, but did not actually delete or dipose of it, as in an observer, or removing entity references from the selection set.

" delete()" was used when you actually wanted to dispose of something, such as deleting an attribute, dictionary, or a set.

So the question is.. did they follow their OWN conventions with these new methods??

[thomthom]

And why would the delete method be part of Materials instead of Material ?

[Dan Rathbun]

@thomthom said:

And why would the delete method be part of Materials instead of Material ?

Because self.kill is suicidal, socially unacceptable, and often religiously repugnant.

Seriously, an object does not often dispose of itself, especially when it's a member of a collection. The collection class has a method(s) to dispose of one (or more,) of it's members. Ie Array instance methods: .shift, .pop, .slice etc....

[thomthom]

entity.erase! ...

[Dan Rathbun]

@thomthom said:

entity.erase! ...

(1) that's not a Ruby method.. it's a Google written method (that doesn't really follow convention.)

(2) It uses the **!** ("in place",) suffix to denote the operation is immediate against the receiver... BUT it is actually just an alias for Sketchup::Entities#erase_entities(receiver)

.. yes there are bound to be variances ... likely caused by human error.

[thomthom]

Cursed! Materials.remove is bugged! http://forums.sketchucation.com/viewtopic.php?f=180&t=34217&p=301158#p301158

[TIG]

So material.remove doesn't exist BUT is in the API docs ???
Then materials.remove(material) exists but doesn't work as expected !!!

What is going on ???

At least my 'clunky' old material.delete works... and it reverts all objects that were using that material to have 'nil'! [but it does have to traverse all model.entities and definition.entities too to achieve it !]

[thomthom]

@tig said:

So material.remove doesn't exist BUT is in the API docs ???

Yes - the docs where wrong.

@tig said:

At least my 'clunky' old material.delete works... and it reverts all objects that were using that material to have 'nil'! [but it does have to traverse all model.entities and definition.entities too to achieve it !]

Yea. When using Materials.remove you still need to iterate the whole model, but at least one doesn't ahve to create temp groups and use purge.
Too bad this method is bugged when it finally appeared.

But material.name= seem to work fine. Which is very good as one doesn't need to clone a new variant of the material.

[jhauswirth]

@tig said:

Then materials.remove(material) exists but doesn't work as expected !!!

What is going on ???

It is working as intended. It would all make sense if you guys could see how the Ruby API is implemented in SU.
The Ruby API is a very thin wrapper around our C++ code. So in this case we have a CMaterialManager class
in SU and the Ruby Materials class wraps CMaterialManager. When you get Materials from the model you get the
Ruby wrapper around CMaterialManager. CMaterialManager knows nothing about the model. Its just
a std::vector<CMaterial*> CMaterialVec; and all Materials.remove does is call
CMaterialManager.RemoveMaterial(CMaterial*), which just removes the given material from the CMaterialVec.
What everyone is asking for is probably a new method in model called model.remove_material (you guys can start
another thread on what it should be called). This new method would live in model because
model owns Materials and the entities that are assigned the materials. So model has all the info
needed to implement what you are asking for. Sorry for messing this up, I sneaked these new methods
in right before release which didn't get properly reviewed by the beta group because there were no
release notes made for the new methods.

[thomthom]

@jhauswirth said:

It is working as intended. It would all make sense if you guys could see how the Ruby API is implemented in SU.
The Ruby API is a very thin wrapper around our C++ code.

In this case I think it might have been too thin. I can't think of a case where you want to remove a material just from the manager and not the model entities. As it is now it needs to be clearly documented that it orphans the material and the developer that uses it needs to takes care of removing it from the model. Because once it's been orphaned one can't locate it in the material collection.

@jhauswirth said:

What everyone is asking for is probably a new method in model called model.remove_material (you guys can start
another thread on what it should be called). This new method would live in model because
model owns Materials and the entities that are assigned the materials. So model has all the info
needed to implement what you are asking for.

But wouldn't that be inconsistent Pages.erase ? Pages internally contain a reference to it's owner Model via .parent. Couldn't materials.remove also do this? Just seems more neater organized that way. And it's where I'd be starting to look if I was looking for such a method.

@jhauswirth said:

Sorry for messing this up, I sneaked these new methods
in right before release which didn't get properly reviewed by the beta group because there were no
release notes made for the new methods.

These method has been high on the request list, so it's good to see it. But yes, would have been good if they had gone through at least one round of testing.
The Material.name= appear to work as expected though. It's just this Materials.remove which has potential for causing issues. But at least it allows us to remove materials from the list without purging and creating temp geometry etc. I already made a wrapper for the function that remove the material from the entities before removing it from the material manager, but I wonder if it would have been faster if done natively from SU instead of via the Ruby API?

[thomthom]

@dan rathbun said:

@thomthom said:

But there is no knowing of which other plugins has done this.

Dont say there is no way, just because you don't know how (..YET,) ... remember Ruby is cool! Ruby will find a way, or allow a way through it's immaculate dynamistic glory.

.method_added http://stackoverflow.com/questions/175655/how-to-find-where-a-ruby-method-is-defined-at-runtime

I'm thinking I could make a debugging monitoring class that loads first and monitors the base Ruby and SketchUp classes and modules for extensions.

[Jim]

tattletale.

I'm not sure you need to "monitor", but an as-needed check of the files in plugins would be sufficient.

[thomthom]

@jim said:

I'm not sure you need to "monitor", but an as-needed check of the files in plugins would be sufficient.

Yes, a debug tool, that's what I intended. "Monitor" because one couldn't just get the load path for any method. Need to hook into at the beginning before anything else.

[Dan Rathbun]

@unknownuser said:

I'm thinking I could make a debugging monitoring class that loads first and monitors the base Ruby and SketchUp classes and modules for extensions.

I also.. have a couple of methods proto'd out. I was thinking they need to be in a common namespace. How about: SKX::Dev ??

@jim said:

tattletale.

Yep.. I didn't want to "publish" the method publically, as there can be only one "monitor", or they'd be fighting each other to override it.

@unknownuser said:

"Monitor" because one couldn't just get the load path for any method. Need to hook into at the beginning before anything else.

@jim said:

I'm not sure you need to "monitor", but an as-needed check of the files in plugins would be sufficient.

Much more efficient to 'hook in at the beginning' that way you can detect when a rbs file does an override. Ruby can tell you the file and line number without having to parse actual files. (Even Kernel.set_trace_function can do it.)
One issue however is that "the method" will report ALL methods created once monitoring begins, so definately some filtering will be needed to ignore methods added to custom classes and modules. Otherwise you'll flood $stdout or the logging object (file, hash etc.)