Observers WhishList

[mtalbott]

I'm a newbie to Sketchup Ruby API so this might be me and not the observer...

When using a selection observer to control the visibility of all entities based on the attributes of the selected entity, it allows me(and I don't want to be allowed) to select hidden entities even when "show hidden geometry" is unchecked.

This is my first use of an observer so maybe I just have to play with it more but I was thinking this might be a limitation of the observer.

[thomthom]

When using a selection observer to control the visibility of all entities based on the attributes of the selected entity, it allows me(and I don't want to be allowed) to select hidden entities even when "show hidden geometry" is unchecked.

You will see that SU, when you triple click a mesh, will select hidden geometry, and display it as dotted edges.

Check the entity's .hidden? or .visible? property along with Sketchup.active_model.rendering_options['DrawHidden'] to determine if an entity is visible and if the user has Hidden Geometry on.

[mtalbott]

Check the entity's .hidden? or .visible? property along with Sketchup.active_model.rendering_options['DrawHidden'] to determine if an entity is visible and if the user has Hidden Geometry on.

thomthom,
thanks for responding to my issue. However, with my limited knowledge, checking hidden or visible is only good after the selection has been made. I don't know how to effect what can be selected in the first place.

The issues can be simplified to this: all entities have a dictionary with an attribute value set to either "A" or "B". The script's job is to watch the selection that the user makes and based on what is selected, change the visibility. If an entity with the "A" tag is selected, only other "A" entity are visible and visa-versa. Furthermore, if nothing is selected both "A" and "B" entities should become visible again. The problem is that after I start the observer and select an "A" entity all of the "B" entities are hidden but if I go to select a different entity (which should be another "A" because that is all that is visible), the selection tool will pick the entity as if both "B" and "A" are visible. So if there is a "B" entity is in front of the "A" that I want to select it will select the invisible "B". This also goes for selecting in white space.

I figure that I need to tell sketchup that something has changed and it should get it's act together but that is where I've fallen short and thought maybe the selection observer was just not quite observant enough.

[thomthom]

I'm a bit surprised there hasn't been more activity in this thread...

[Dan Rathbun]

there is NO Sketchup::StylesObserver

But the Styles class has a few 'observer-like' methods:
Styles.update_selected_style
This method is a boolean method (which should have a '?' at the end of it's name.) The use of this method is confusing (partly as the example does not show the style being selected.)
Styles.active_style_changed
(again, should have a '?' at the end of it's name.)
This is a session boolean, changes anytime after saving; but no way to trigger an event.

Would it be better to create a StylesObserver class?
That had methods such as:
--- (edit) names changed
onStyleSetAdd(styles, newStyle)
onStyleSetCreate(styles, newStyle, fromStyle)
onStyleSetChosen(styles, oldStyle, newStyle)
--- (edit) name added
onStyleSetRename(styles, style, oldName, newName)
onStyleSetRedescribe(styles, style, oldText, newText)
onStyleSetEdited(styles, style, styleOptions, optionsChangedHash)
(for Bulk handling instead of single option handling.)

Purge methods
(as in previous post (Suggested) onBeforePurge & onAfterPurge)
onBeforePurge(styles, stylesUnusedObjectArray)
onAfterPurge(styles, removedStylesArray, purgeResult)


--- (edit) the following withdrawn
onStyleEdit(styles, style, option, oldValue, newValue)*
* probably will need to implement a "StylesOptions" OptionsProvider
-- in favor of updates to
RenderingOptionsObserver as in post:
Re: StyleOptions / StyleOptionsObserver

[thomthom]

Before, Styles where called Rendering Options. So look at the RenderingOptions class. You have a RenderingOptionsObserver class: http://code.google.com/intl/nb/apis/ske ... erver.html

Same thing as Scenes in the SU UI is Pages in the API.

[Dan Rathbun]

Before, Styles where called Rendering Options. So look at the RenderingOptions class. You have a RenderingOptionsObserver class: http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/renderingoptionsobserver.html

OK looked at that... seems like the RenderingOptionsObserver class needs an overhaul:

• Need to alias (rename) as: StyleOptionsObserver
• Need to deprecate the old name.

The type is an internal number that indicates what was changed. You will need to watch the observer for numbers you are interested in.

• That is clumsy! (or lazy programming.) Ruby is a high-level language, lets have the same identifier keys as used in the RenderingOptions collection class.
• RenderingOptions also needs to be aliased or renamed StyleOptions.
• Need to deprecate the old name.

This only covers the onStyleEdit method I proposed in the previous post, which is actually named onRenderingOptionsChanged, however, it fails to send any detail, it only tells (by ordinal,) what options WAS changed. I think it should pass oldValue and newValue as well.

So reproposing the method as:
onStyleOptionsEdit(styleOptionsCollection, optionKeyname, oldValue, newValue)
Could still have old method that sends ordinal number, as:
onStyleOptionsChange(styleOptionsCollection, optionNum)

• Need to deprecate the old name.

STILL, need as in previous post, a 'higher' level StylesObserver for triggering events when Styles are manipulated as a whole set (saved to, or loaded from files.) We can call these a StyleSet.

• It is possible that those methods could go in the AppObserver rather than create a new observer class.

[TIG]

I think you are missing a practical point - you can change a "Rendering Option" without changing the current Scene's "Style" - e.g. switching Xray-mode on won't affect the "Style" BUT it will affect what is displayed on screen [i.e. "Rendered"]. Therefore shouldn't there be two sorts of Observer - one to watch for changes to the "Rendering Options Settings" and another to watch for "Style Changes"

[thomthom]

I think you are missing a practical point - you can change a "Rendering Option" without changing the current Scene's "Style" - e.g. switching Xray-mode on won't affect the "Style" BUT it will affect what is displayed on screen [i.e. "Rendered"]. Therefore shouldn't there be two sorts of Observer - one to watch for changes to the "Rendering Options Settings" and another to watch for "Style Changes"

If you enable X-Ray mode you change the current Style.

[TIG]

I think you are missing a practical point - you can change a "Rendering Option" without changing the current Scene's "Style" - e.g. switching Xray-mode on won't affect the "Style" BUT it will affect what is displayed on screen [i.e. "Rendered"]. Therefore shouldn't there be two sorts of Observer - one to watch for changes to the "Rendering Options Settings" and another to watch for "Style Changes"

If you enable X-Ray mode you change the current Style.

That way you don't change an existing Scene's Style per se - the current Render Settings are temporary changes in that View not the Scene's defined Style - if you change back to that Scene tab the Style should be refreshed back as it was until you save its changes - I know that Xray mode is perhaps a bad example in that it transcends Style settings.

My point is that what is being Rendered in a View and a Scene's Style are different things. One is transient, one is fixed. Changing the Style changes the Render Setting it uses, but you can change the Render Settings without changing a 'named' Style - the confusion is that changing the Render Settings makes a 'temporary' Style that is used in that View from then on until you change settings again or go back to another saved Style - you can the save this temp-style as a new Style or use it to update another already defined Style...

My point was that Styles and Render Settings are linked but different as any Style's settings are not necessarily equal to the current Render Options ?

[thomthom]

Ah. Gotcha!

[Dan Rathbun]

Therefore shouldn't there be two sorts of Observer - one to watch for changes to the "Rendering Options Settings" and another to watch for "Style Changes"

Yes possibly. The API is WAY out of date on this subject and not very clear.

Likely that Rendering Options came first (before Scene Styles were 'invented'?)

(in regard to Rendering Options) The majority of the rendering information returned exists in the Model Info > Display section of SketchUp

But that is no longer true!
There is no 'Display' section in the Model Info dialog in 7.x!

[thomthom]

Don't think I've ever seen a Display section. But I've only used SU since v6.x.

[Dan Rathbun]

- the current Render Settings are temporary changes in that View not the Scene's defined Style - if you change back to that Scene tab the Style should be refreshed back as it was until you save its changes - I know that Xray mode is perhaps a bad example in that it transcends Style settings.

My point is that what is being Rendered in a View and a Scene's Style are different things. One is transient, one is fixed.

I don't see any difference in practice.
I have 4 scenes tabs defined and have the Style dialog open in the edit pane.

Whatever I change in the Style dialog changes on the App toolbars or menus.

Whatever I change on the menus (ie Hidden Geometery,) or toolbars (shaded, xray, wireframe etc.,) is immediately echoed in the Style dialog Edit pane.

After making changes, switching between Scenes makes no changes, however I suppose all scenes are set to the same Style.

If I purposely try to set one scene to a different style, it changes, then I switch to another scene it switches back; returning to the previous scene (which I had changed does not change the Style.) It seems there is a default Model Style.

This is confusing.

[Dan Rathbun]

there is NO Sketchup::StylesObserver

Made a few edits to proposed methods.
see original post: StylesObserver

[Dan Rathbun]

... For example, OnEntityChanged, what constitutes a 'change'?

Yea - I spent some time on this because I was setting attributes - which seems to be a change. Not sure if I want that to trigger. At least not most of the times. attributes are like meta data.
maybe onChange for geometric changes, and onAttribChange(dict, key, oldVal, newVal) for the attribute meta data?

Do changes to an Attribute currently fire onEntityChanged events?
What about adding or deleting an attribute from a Dictionary?
What about adding or deleting a Dictionary from an Entity?

[Dan Rathbun]

... For example, OnEntityChanged, what constitutes a 'change'?

Yea - I spent some time on this because I was setting attributes - which seems to be a change. Not sure if I want that to trigger. At least not most of the times. attributes are like meta data.
maybe onChange for geometric changes, and onAttribChange(dict, key, oldVal, newVal) for the attribute meta data?

Do changes to an Attribute currently fire onEntityChanged events?
What about adding or deleting an attribute from a Dictionary?
What about adding or deleting a Dictionary from an Entity?

EDIT
I asked this because, it would lead to whether we need EntityObserver methods:
onBeforeAttributeAdd(entity, dict, key, value)
onAfterAttributeAdd(entity, dict, key, value, result)
onBeforeAttributeDelete(entity, dict, key, value)
onAfterAttributeDelete(entity, dict, oldKey, oldVal, result)
Also, ThomThom's example needs the entity handle passed.
onAttribChange(entity, dict, key, oldVal, newVal)*
* would assume change result was 'true' (successful)

onBeforeDictionaryAdd(entity, newDict)
onAfterDictionaryAdd(entity, dict, result)
onBeforeDictionaryDelete(entity, dict)
onAfterDictionaryDelete(entity, oldDict, result)

Also would a DictionaryObserver be necessary?
(I'd think not as most Attribute and Dictionary functions are available thru the Entity object.)

[thomthom]

So what's the latest gossip from the Google camp on this topic?

[Dan Rathbun]

need AppObserver.onCloseModel

It is often used to attach other observers to each model as it is opened or started. This ensures that your observers are watching all open models.
http://code.google.com/apis/sketchup/docs/ourdoc/appobserver.html

In an MDI application (as the Mac is now, and hopefully the PC will be in upcoming versions,) there needs to be a way to detect that an MDI child window has been closed, so scripts can do cleanup, such as unattaching observers that may have been attached using onNewModel or onOpenModel.

Of course on the PC, at the current time, Sketchup is not yet an MDI application; and to close the active model, a user would either open a new model (firing the onNewModel event,) open another model from a file (firing the onOpenModel event,) OR shut down Sketchup (firing the onQuit event.)
_

[Dan Rathbun]

_
I've noticed there does not seem to be Observers for classes:

• Importer
• Exporter
• TextureWriter

Anyone think there's any need here?
_

[thomthom]

Can't see any reason.
It's the changes in the model that we need to be aware of. Importer, Exporter, and TextureWriter doesn't affect the model.
..well, the importer imports geometry, but the EntitiesObserver and DefinitionObserver and InstanceObserver should take care of that.

[Dan Rathbun]

_
Sketchup::SelectionObserver

This observer needs fixing! I would put this in the high priority group.

Per ThomThom's Observer Review "State of Observers"
http://forums.sketchucation.com/viewtopic.php?f=180&t=20676&start=0#p173630

Sketchup::SelectionObserver

.onSelectionAdded never triggers
.onSelectionRemoved never triggers.

Instead,
.onSelectionBulkChange and .onSelectionCleared always triggers.
_

[thomthom]

Why doesn't this observer have its own class documented as the other observers? http://code.google.com/intl/nb/apis/ske ... e_observer

[Dan Rathbun]

FrameChangeObserver

Why doesn't this observer have its own class documented as the other observers? http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/pages.html#add_frame_change_observer

I would guess that this was a pre-version 6 observer implementation, added before they 'set a standard' in version 6 for true observer prototypes defined under the Sketchup module. And that when they did add those formally defined Observer classes in version 6, this one fell through the cracks.

I checked the Object list... and there is no observer prototype named 'FrameChangeObserver' defined.
I checked the Sketchup::Pages class for it's methods:

Code: Select all

pages.public_methods(false).sort
["[]", "add", "add_matchphoto_page", "add_observer", "count", "each", "erase", "parent", "remove_observer", "selected_page", "selected_page=", "show_frame_at", "size", "slideshow_time"]

There are NO methods:

• add_frame_change_observer
• remove_frame_change_observer

This information is OBSOLETE in the API, and should be removed.

A coder (currently) would have to use the Sketchup::ViewObserver, onViewChanged method to detect when the change of view finished.

IF there is a need (for the functionality of a FrameChangeObserver,) you might propose a Sketchup::AnimationObserver class that has this callback function and perhaps others?

Jim might want to weigh in on this, as he has been working on Animation lately.

@Jim : Questions:

• Would an attached AnimationObserver be expected to slow the framerates?
• Would an AnimationObserver even be necessary? (As really the Animation interface, is somewhat like an observer itself. The pause, resume and stop methods act like observer callbacks.)

_

[ptitjes]

_
Sketchup::SelectionObserver

This observer needs fixing! I would put this in the high priority group.

I highly second that request! SelectionObserver is broken.

Per ThomThom's Observer Review "State of Observers"
http://forums.sketchucation.com/viewtopic.php?f=180&t=20676&start=0#p173630

Sketchup::SelectionObserver

.onSelectionAdded never triggers
.onSelectionRemoved never triggers.

Instead,
.onSelectionBulkChange and .onSelectionCleared always triggers.
_

Here even onSelectionCleared is not even triggered. (SU 7.1 (7.1.5803) on MacOS SnowLeaopard) This makes working on selections quite impossible and you can't do that in a right way.

Also, plugins should be loaded before any new model is created in SU. Because AppObservers are not triggered for the initial new model open when lauching sketchup.

Both those issues could be easily fixed. I don't know whether sketchup dev team is reading this forum, but please fix that!

Didier.

[thomthom]

Both those issues could be easily fixed. I don't know whether sketchup dev team is reading this forum, but please fix that!

This post was started by a Google Sketchup employee.

[Dan Rathbun]

Sketchup::AppObserver

Anyone interested in any of the following event methods?

Extensions
Sketchup.register_extension
onRegisterExtension( extObj, loadFlag, regResult )
onLoadExtension( extObj, loadResult )

* onUnloadExtension needs fixing. Currently passes the extension name, BUT text names are not necessarily unique, for example there are several extensions, by several different authors called "SelectionMemory".
In addition what would we do with a textname anyway? There is no method to find an ExtensionObject by searching using a textname, as well as even having access to the ExtensionsCollection/Manager.
We definately need the object handle passed, then we can access any of the extensions attributes, including the name, example:
onUnloadExtension( extObj )


Internet Connection
IF Sketchup.is_online returns false, an Observer could be used to watch for an when an Internet Connection is established. This may be needed for some extensions that download help information, or textures or other files from the internet (especially when the user has a dial-up connection.)
onInternetConnect
onInternetDisconnect


Send Action
fired by Sketchup.send_action
onBeforeSendAction( action )
onAfterSendAction( action, result )


Thumbnails Bulk events
Would likely be used by Gallery or webpage generator Plugin extensions.
onAfterSaveThumb( obj, img, result )
onBeforeSaveThumb( obj, img )

When fired by:
ComponentDefinition.save_thumbnail
Model.save_thumbnail
View.write_image (if img is thumbSize)

• obj is the source object handle
• img is the output imgStringPathname

When fired by:
Sketchup.save_thumbnail

• obj is the input skpStringPathname
• img is the output imgStringPathname

_

[thomthom]

Can't say I've ever wanted/needed those events. It's the events that relates to model changes that I'd wish where working reliably.

[dkendig]

We have always had a hard time ensuring our plugin's data is properly serialized in to the scene prior to a save. Now we serialize after every - single - change... and it slows things down a little. The proposed solution for onSaveModel would be wonderful... oh please magical Google genies... please fix these observer issues. Here's a post we put in the discussion groups a while back when we were pulling our hair out:

http://groups.google.com/group/Ruby-API/browse_thread/thread/bf156b08bdb9ba71/5b9ac6cc4a3bb83c#5b9ac6cc4a3bb83c

[tomot]

It really bugs me! when I'm doing a load "Filename.rb" into the Ruby Console, that the revised "Filename.rb" may run as expected, only to find out that "Filename.rb" really didn't work. because I had not actually quit the currently running SU.

I'm not sure if this is an Observer issue: It would be really nice if there was a closer OBSERVATION on the part of the API that scripts work or don't work. I don't ever recall having to Quit AutoCad, and restarting it each time I was testing Lisp routines.

In fact GLD is Archicad's API, is even more elegant, the code is written totally within the ArchiCad application in its own GLD window, errors are flagged without ever having to quit the main ArchiCad application.