Observers WhishList

Observers WhishList

Postby snicolo » Thu Dec 10, 2009 11:48 pm

Hi All,

In order to try to prioritize which Observer to fix first I would love to collect some data on the following topics:

what are the Observers that you would like to see added to SketchUp?

which are the observers that you would like to use but that do not work?

When I have some data I am hoping to push for fixing/adding those.

thanks.
Simone.
0
User avatar
snicolo 
 

Re: Observers WhishList

Postby thomthom » Fri Dec 11, 2009 12:16 am

The current ones that's bugged which I would have great use of is;
  • EntityObserver
  • EntitiesObserver
  • DefinitionObserver
  • InstanceObserver
These are interesting in order to know what's being created, deleted and modified. And the events that trigger on delete should trigger before the entity is deleted, so we can perform cleaning up actions such as removing observers etc.

To accompany these, it would be nice to have persistent entity identifiers. That way, we can store the persistent ID of an entity in an attribute, and when the model is opened again we can use this id to access the entities directly and reassign observers without having to parse the entire model.

An event that triggers when it's safe to perform model changes would be good. So we can stack up modification, based on information from the other events, and execute them during this safe event.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Observers WhishList

Postby Chris_at_Twilight » Fri Dec 11, 2009 6:00 pm

It would be great if the MaterialObserver 'onMaterialChange' would trigger in event of any change to the material (color, alpha, texture scale, etc). If that's not possible, an additional method that did it would be nice.
0

Chris_at_Twilight 
Twilight Render
 

Re: Observers WhishList

Postby Jernej Vidmar » Fri Dec 11, 2009 8:00 pm

First off, I totally agree with ThomThom's suggestions and add my vote for it.

In addition to that, it would be great if you can add the observer, that would give us some feedback (i.e. event, value) when an event triggered via Value Control Box occurs.
0

Jernej Vidmar 
Modelur
 

Re: Observers WhishList

Postby thomthom » Fri Dec 11, 2009 8:26 pm

An event for layer content change would be nice, so one can detect when entities are added and removed from layers.

And these events that trigger when stuff is added and removed:
it would be nice if a bulkadd and bulkremove event was triggered when entities are added and removed within between a model.start_operation and model.commit_operation.

Related to that, I noticed that when you add an entities observer, and you then use Move+Copy or Rotate+Copy the add/remove events trigger multiple times.
Say I Move+Copy a group within the Entitites collection I monitor;
I Move+Copy and type in * 5 to make 5 copies, the add event then trigger for each copy.
If I then type in *7 instead afterward, I then get 5 remove events followed by 7 add events. This isn't desirable. Instead I'd like one event call after each element has been added/removed.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Observers WhishList

Postby thomthom » Fri Dec 11, 2009 8:28 pm

Material.onPaint(entity)
and/or
Materials.onPaint(material, entity)
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Observers WhishList

Postby thomthom » Fri Dec 11, 2009 8:33 pm

Tools observer that let you determine what custom Ruby tool is being used.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Observers WhishList

Postby Chris Fullmer » Fri Dec 11, 2009 10:51 pm

I don't have a specific request off the topf of my head. I don't use observers very often.

But my request would be that the observers that are in the API should work. smoothly and consistently. And the API should document better how they work, what values they return, when they kick in, etc.

So for me it just be nice if everything worked.

Chris
0
Lately you've been tan, suspicious for the winter.
All my Plugins I've written
User avatar
Chris Fullmer 
SketchUp Team
SketchUp Team
 

Re: Observers WhishList

Postby Whaat » Sat Dec 12, 2009 2:31 am

Here's a few ideas:
- make the materials observer for Mac and PC behave the same way. On Mac, the observer doesn't fire (onMaterialSetCurrent) unless you paint a face, whereas on PC, it fires when you click on the icon in the Materials Window
- Make them more stable. Observers seem to be a leading cause of crashes especially if you are using entity and entities observers
- An idea that's related to observers: I would like a method to determine the time a component definition was last modified. Modification would be any change for any entity in the component definition including any material assignments that have changed for any entity in the definition. I would think that the Entities Observer should accomplish this but, as I recall, this only would fire in a few specific circumstances.
- It would be nice if the API docs would say all of the specific events that are supposed to cause an observer to fire. For example, OnEntityChanged, what constitutes a 'change'? It shouldn't be up to the developers to have to endure countless hours of testing to figure out what events actually trigger the observers.

Thanks for working to improve this stuff!
0

Whaat 
PluginStore Author
PluginStore Author
 

Re: Observers WhishList

Postby thomthom » Sat Dec 12, 2009 9:50 am

Whaat wrote:- It would be nice if the API docs would say all of the specific events that are supposed to cause an observer to fire. For example, OnEntityChanged, what constitutes a 'change'? It shouldn't be up to the developers to have to endure countless hours of testing to figure out what events actually trigger the observers.

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?
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Observers WhishList

Postby fredo6 » Sat Dec 12, 2009 5:10 pm

On my side, the priority should be:

1) an APP and Model Observer which behaves correctly in reliably for events: Create New Model, Open Existing model, whatever method is used (.i.e from whithin Sketchup, via revert, etc...). Today the Observer is bugged and does not trap events in case you open a model, but get through a dialog box to save the current one before. This is critical, because these observers are usually the place where you will set or reset all others.

2) a new observer event onSaveBefore, which is fires before the model is saved by the user. This gives an opportunity to save parameters (usually as attributes) into the model.

Fredo
0
User avatar
fredo6 
PluginStore Author
PluginStore Author
 

Re: Observers WhishList

Postby Dan Rathbun » Sun Dec 13, 2009 8:39 am

Fredo6 wrote:2) a new observer event onSaveBefore, which is fires before the model is saved by the user.

The tradition in naming events [using DHTML events as a reference,] seems to be:
  1. Event names begin with "on".
  2. If a modifier is NOT needed, the event is usually always an after event, such as onclick. The event cannot fire until after the click occurs. (There are exceptions, such as onunload, which is a before event. Some browsers such as MSIE implement a non-standard alias called onbeforeunload. Anyhow.. unmodified names are or should be unambigious as to when they fire; ie: onunload would not be any use if it fired after the unload happens.)
  3. If a modifier IS needed, there are two kinds:
    • Verb based: the eventnames end with a verb, with the modifier placed between "on" and the verb.
    • :
      • onbeforeEventverb
      • onafterEventverb
    • Noun based: the noun follows the "on", with a modifier at the end.
      • onEventnounstart
      • onEventnounstop
So, referencing the URL below and the way most SU API events are named, the eventname Fredo wants should be called ModelObserver.onBeforeSaveModel.
The SU API for most Observer events follows close to the way that DHTML events are named. (There are events in both APIs that did not follow the naming 'convention', for whatever reason...?)

ref: DHTML events
http://msdn.microsoft.com/en-us/library/ms533051(VS.85).aspx

I don't know why the W3C named events this way, but they did. (IMHO, I think even some of the Noun-based event names would be more clear with a 'before' or 'after' between the 'on' and noun.)

The list at MSDN may give some readers ideas as to similar events or observers they would like in the SU API.
0
    I'm not here much anymore. But a PM will fire email notifications.
    User avatar
    Dan Rathbun 
    PluginStore Author
    PluginStore Author
     

    (Suggested) onBeforePurge & onAfterPurge

    Postby Dan Rathbun » Mon Dec 14, 2009 1:05 pm

    suggested Purge event methods,
    fire ONCE regardless of entities removed:
    (allows bulk handling in one event, instead of dealing with multiple events firing for each purged object.)

    onBeforePurge(collection, itemsObjectArray)
    onAfterPurge(collection, itemsStringArray, purgeResult)

    (onAfterPurge must return a an array of string names because the objects are now gone; the purgeResult would be the boolean returned from .purge_unused)

    for: DefinitionsObserver, LayersObserver, MaterialsObserver, StylesObserver
    (and any other new observer added that gets a .purge_unused method)
    0
      I'm not here much anymore. But a PM will fire email notifications.
      User avatar
      Dan Rathbun 
      PluginStore Author
      PluginStore Author
       

      Re: Observers WhishList

      Postby thomthom » Mon Dec 14, 2009 1:37 pm

      thomthom wrote:An event that triggers when it's safe to perform model changes would be good. So we can stack up modification, based on information from the other events, and execute them during this safe event.

      Do I understand it correctly that the TransactionCommit event is suppose to be doing this?
      There is another issue here though. Say that TransactionCommit was working and you use that to perform actions which you have queued up during various model change events - then those changes will also trigger an TransactionCommit event. Would be useful to have some more into to what event was completed - or started. As oppose to just getting an event that says "some operation" started/ended.
      0
      Thomas Thomassen — SketchUp Monkey & Coding addict
      List of my plugins and link to the CookieWare fund
      User avatar
      thomthom 
      PluginStore Author
      PluginStore Author
       

      Re: ToolsObserver

      Postby Dan Rathbun » Mon Dec 14, 2009 1:43 pm

      thomthom wrote:Tools observer that let you determine what custom Ruby tool is being used.

      YES I agree.
      Currently all custom Tools are reported as name="RubyTool" id="50003" state=nil
      (or similar.)
      In my custom Tool, I've made attribute getters tool_name, tool_id, tool_state but the ToolsObserver didn't ask for them I suppose. (or maybe it's the Tools collection?)

      Also the Tools collection does NOT work with custom RubyTools. Which may be the ToolObservers' problem as it gets it's info from the Tools collection.

      ----
      (Addition:) I'd like some VCB methods (or extra parameters passed by current methods,) to supply VCB Label and VCB value.
      If new methods, something like:
      onVCBlabelchange( tools, tooldata, vcblabel )
      onVCBvalueentry( tools, tooldata, vcbvalue )
      tooldata = Array[ tool_name, tool_id, tool_state ]

      reason for labelchange event, is that we cannot rely on tool states as they vary too much, and worse, not all standard tools even use / change a tool state. So in order to know where a tool is in it's process we might be able to use what's displayed for the VCB prompt label.

      It would also be nice to get the VCB value after user entry from outside of a standard tool. (I know we CAN do it within our own custom tools using the onUserText method.) Uses, well I can think of implementing a entry history for standard tools, for one.
      0
        I'm not here much anymore. But a PM will fire email notifications.
        User avatar
        Dan Rathbun 
        PluginStore Author
        PluginStore Author
         

        Re: Observers WhishList

        Postby mtalbott » Wed Dec 16, 2009 8:52 pm

        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.
        0

        mtalbott 
         

        Re: Observers WhishList

        Postby thomthom » Wed Dec 16, 2009 9:00 pm

        mtalbott wrote: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.
        0
        Thomas Thomassen — SketchUp Monkey & Coding addict
        List of my plugins and link to the CookieWare fund
        User avatar
        thomthom 
        PluginStore Author
        PluginStore Author
         

        Re: Observers WhishList

        Postby mtalbott » Wed Dec 16, 2009 9:45 pm

        thomthom wrote: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.
        0

        mtalbott 
         

        Re: Observers WhishList

        Postby thomthom » Sun Dec 20, 2009 3:39 pm

        I'm a bit surprised there hasn't been more activity in this thread...
        0
        Thomas Thomassen — SketchUp Monkey & Coding addict
        List of my plugins and link to the CookieWare fund
        User avatar
        thomthom 
        PluginStore Author
        PluginStore Author
         

        StylesObserver

        Postby Dan Rathbun » Sun Dec 20, 2009 11:38 pm

        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
        0
        Last edited by Dan Rathbun on Mon Dec 21, 2009 2:01 pm, edited 4 times in total.
          I'm not here much anymore. But a PM will fire email notifications.
          User avatar
          Dan Rathbun 
          PluginStore Author
          PluginStore Author
           

          Re: Observers WhishList

          Postby thomthom » Sun Dec 20, 2009 11:46 pm

          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.
          0
          Thomas Thomassen — SketchUp Monkey & Coding addict
          List of my plugins and link to the CookieWare fund
          User avatar
          thomthom 
          PluginStore Author
          PluginStore Author
           

          Re: StyleOptions / StyleOptionsObserver

          Postby Dan Rathbun » Mon Dec 21, 2009 11:17 am

          thomthom wrote: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.
          Sketchup Ruby API wrote: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.
          0
            I'm not here much anymore. But a PM will fire email notifications.
            User avatar
            Dan Rathbun 
            PluginStore Author
            PluginStore Author
             

            Re: Observers WhishList

            Postby TIG » Mon Dec 21, 2009 12:07 pm

            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" :?:
            0
            TIG
            User avatar
            TIG 
            Global Moderator
             

            Re: Observers WhishList

            Postby thomthom » Mon Dec 21, 2009 12:26 pm

            TIG wrote: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.
            0
            Thomas Thomassen — SketchUp Monkey & Coding addict
            List of my plugins and link to the CookieWare fund
            User avatar
            thomthom 
            PluginStore Author
            PluginStore Author
             

            Re: Observers WhishList

            Postby TIG » Mon Dec 21, 2009 12:57 pm

            thomthom wrote:
            TIG wrote: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 ?
            0
            Last edited by TIG on Mon Dec 21, 2009 1:03 pm, edited 1 time in total.
            TIG
            User avatar
            TIG 
            Global Moderator
             

            Re: Observers WhishList

            Postby thomthom » Mon Dec 21, 2009 1:01 pm

            Ah. Gotcha!
            0
            Thomas Thomassen — SketchUp Monkey & Coding addict
            List of my plugins and link to the CookieWare fund
            User avatar
            thomthom 
            PluginStore Author
            PluginStore Author
             

            Re: Observers WhishList

            Postby Dan Rathbun » Mon Dec 21, 2009 1:12 pm

            TIG wrote: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'?)

            Sketchup Ruby API wrote:(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!
            0
              I'm not here much anymore. But a PM will fire email notifications.
              User avatar
              Dan Rathbun 
              PluginStore Author
              PluginStore Author
               

              Re: Observers WhishList

              Postby thomthom » Mon Dec 21, 2009 1:15 pm

              Don't think I've ever seen a Display section. But I've only used SU since v6.x.
              0
              Thomas Thomassen — SketchUp Monkey & Coding addict
              List of my plugins and link to the CookieWare fund
              User avatar
              thomthom 
              PluginStore Author
              PluginStore Author
               

              Re: Observers WhishList

              Postby Dan Rathbun » Mon Dec 21, 2009 1:33 pm

              TIG wrote:- 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.
              0
                I'm not here much anymore. But a PM will fire email notifications.
                User avatar
                Dan Rathbun 
                PluginStore Author
                PluginStore Author
                 

                Re: StylesObserver

                Postby Dan Rathbun » Mon Dec 21, 2009 1:44 pm

                Dan Rathbun wrote:there is NO Sketchup::StylesObserver

                Made a few edits to proposed methods.
                see original post: StylesObserver
                0
                  I'm not here much anymore. But a PM will fire email notifications.
                  User avatar
                  Dan Rathbun 
                  PluginStore Author
                  PluginStore Author
                   

                  SketchUcation One-Liner Adverts

                  by Ad Machine » 5 minutes ago



                  Ad Machine 
                  Robot
                   

                  Next


                   

                  Return to Developers' Forum

                  Who is online

                  Users browsing this forum: No registered users and 7 guests

                  Visit our sponsors: