• Login
sketchucation logo sketchucation
  • Login
πŸ€‘ SketchPlus 1.3 | 44 Tools for $15 until June 20th Buy Now

Observers WhishList

Scheduled Pinned Locked Moved Developers' Forum
59 Posts 18 Posters 110.2k Views 18 Watching
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    thomthom
    last edited by 21 Dec 2009, 12:15

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

    Thomas Thomassen β€” SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund

    1 Reply Last reply Reply Quote 0
    • D Offline
      Dan Rathbun
      last edited by 21 Dec 2009, 12:33

      @tig said:

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

      I'm not here much anymore.

      1 Reply Last reply Reply Quote 0
      • D Offline
        Dan Rathbun
        last edited by 21 Dec 2009, 12:44

        @dan rathbun said:

        there is NO **Sketchup::StylesObserver**

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

        I'm not here much anymore.

        1 Reply Last reply Reply Quote 0
        • D Offline
          Dan Rathbun
          last edited by 21 Dec 2009, 12:51

          @thomthom said:

          @whaat said:

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

          I'm not here much anymore.

          1 Reply Last reply Reply Quote 0
          • D Offline
            Dan Rathbun
            last edited by 21 Dec 2009, 13:01

            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

            I'm not here much anymore.

            1 Reply Last reply Reply Quote 0
            • D Offline
              Dan Rathbun
              last edited by 2 Jan 2010, 02:16

              @dan rathbun said:

              @thomthom said:

              @whaat said:

              ... 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:
              %(#BF0000)[onBeforeAttributeAdd(entity, dict, key, value)
              onAfterAttributeAdd(entity, dict, key, value,]result%(#BF0000)[)
              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)%(#004000)[*

              • would assume change result was 'true' (successful)]%(#BF0000)[onBeforeDictionaryAdd(entity, newDict)
                onAfterDictionaryAdd(entity, dict,]result%(#BF0000)[)
                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.)

              I'm not here much anymore.

              1 Reply Last reply Reply Quote 0
              • T Offline
                thomthom
                last edited by 4 Jan 2010, 10:40

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

                Thomas Thomassen β€” SketchUp Monkey & Coding addict
                List of my plugins and link to the CookieWare fund

                1 Reply Last reply Reply Quote 0
                • D Offline
                  Dan Rathbun
                  last edited by 6 Jan 2010, 10:52

                  need AppObserver.onCloseModel

                  @unknownuser said:

                  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.)
                  _

                  I'm not here much anymore.

                  1 Reply Last reply Reply Quote 0
                  • D Offline
                    Dan Rathbun
                    last edited by 6 Jan 2010, 14:51

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

                    • Importer* Exporter* TextureWriter
                      Anyone think there's any need here?
                      _

                    I'm not here much anymore.

                    1 Reply Last reply Reply Quote 0
                    • T Offline
                      thomthom
                      last edited by 6 Jan 2010, 15:00

                      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.

                      Thomas Thomassen β€” SketchUp Monkey & Coding addict
                      List of my plugins and link to the CookieWare fund

                      1 Reply Last reply Reply Quote 0
                      • D Offline
                        Dan Rathbun
                        last edited by 12 Jan 2010, 16:56

                        _
                        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

                        .onSelectionAddednever triggers
                        .onSelectionRemovednever triggers.

                        Instead,
                        .onSelectionBulkChangeand .onSelectionClearedalways triggers.
                        _

                        I'm not here much anymore.

                        1 Reply Last reply Reply Quote 0
                        • T Offline
                          thomthom
                          last edited by 21 Jan 2010, 14:37

                          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

                          Thomas Thomassen β€” SketchUp Monkey & Coding addict
                          List of my plugins and link to the CookieWare fund

                          1 Reply Last reply Reply Quote 0
                          • D Offline
                            Dan Rathbun
                            last edited by 21 Jan 2010, 19:15

                            FrameChangeObserver

                            @thomthom said:

                            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:

                            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.)
                              _

                            I'm not here much anymore.

                            1 Reply Last reply Reply Quote 0
                            • P Offline
                              ptitjes
                              last edited by 29 Jan 2010, 11:25

                              @dan rathbun said:

                              _
                              Sketchup::SelectionObserver

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

                              I highly second that request! SelectionObserver is broken.

                              @dan rathbun said:

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

                              Sketchup::SelectionObserver

                              .onSelectionAddednever triggers
                              .onSelectionRemovednever triggers.

                              Instead,
                              .onSelectionBulkChangeand .onSelectionClearedalways 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.

                              1 Reply Last reply Reply Quote 0
                              • T Offline
                                thomthom
                                last edited by 29 Jan 2010, 11:35

                                @ptitjes said:

                                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. πŸ˜‰

                                Thomas Thomassen β€” SketchUp Monkey & Coding addict
                                List of my plugins and link to the CookieWare fund

                                1 Reply Last reply Reply Quote 0
                                • D Offline
                                  Dan Rathbun
                                  last edited by 30 Jan 2010, 23:12

                                  Sketchup::AppObserver

                                  Anyone interested in any of the following event methods?

                                  Extensions
                                  Sketchup.register_extension**%(#BF0000)[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.)
                                  %(#BF0000)[onInternetConnect
                                  onInternetDisconnect]

                                  Send Action
                                  fired by Sketchup.send_action%(#BF0000)[onBeforeSendAction( action )
                                  onAfterSendAction( action, result )]

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

                                  When fired by:
                                  %(#BF0000)[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
                                    _

                                  I'm not here much anymore.

                                  1 Reply Last reply Reply Quote 0
                                  • T Offline
                                    thomthom
                                    last edited by 31 Jan 2010, 01:26

                                    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.

                                    Thomas Thomassen β€” SketchUp Monkey & Coding addict
                                    List of my plugins and link to the CookieWare fund

                                    1 Reply Last reply Reply Quote 0
                                    • dkendigD Offline
                                      dkendig
                                      last edited by 25 Feb 2010, 17:27

                                      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

                                      Devin Kendig
                                      Developer

                                      1 Reply Last reply Reply Quote 0
                                      • T Offline
                                        tomot
                                        last edited by 24 Jun 2010, 17:52

                                        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.

                                        [my plugins](http://thingsvirtual.blogspot.ca/)
                                        tomot

                                        1 Reply Last reply Reply Quote 0
                                        • D Offline
                                          Dan Rathbun
                                          last edited by 24 Jun 2010, 21:12

                                          @tomot said:

                                          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.

                                          Is ALL of the code written in the "Filename.rb" wrapped within a second level module block?
                                          It should be.
                                          When it is, from the console, you can type:
                                          <1stLevelModule>.module_eval('remove_const :<2ndLevelModule>')
                                          and the entire 2nd Level module should be undefined. Then type
                                          GC.start to run garbage collection.
                                          Then you can reload your script, and redefine the second level module.

                                          What I'm saying is that all of your plugins should be inside modules, which are ALL inside a master module that is YOUR namespace, such as "Tomot".
                                          example:

                                          module Tomot
                                            module My_Plugin_One
                                              # CONSTANTS
                                              # @@module vars
                                              # class definitions
                                              # method definitions
                                              begin
                                                # run once code
                                              end
                                            end # My_Plugin_One
                                          end # Tomot
                                          

                                          Then when you wish to reload (at the console):
                                          Tomot.module_eval('remove_const :My_Plugin_One')
                                          GC.start
                                          load 'tomot/plugin_one.rb'
                                          (You might even put that in a temporary Tomot module method, to automate the cleanup and reload of any Tomot submodule or subclass, etc. Make a couple of constants Tomot::MODNAME and Tomot::MODPATH that you can change at will, and have the method use those constant's String values in the 1st and 3rd lines, respectively.) Sorta like this:

                                          
                                          Tomot.const_set(;MODNAME,'My_plugin_One')
                                          Tomot.const_set(;MODPATH,'tomot/plugin_one.rb')
                                          def Tomot.reload
                                            module_eval( "remove_const ;#{MODNAME}" )
                                            GC.start
                                            load("#{MODPATH}")
                                          end
                                          
                                          

                                          You'd repeat the process, for other plugins, always defining them WITHIN your master namespace (module Tomot,) and each WITHIN it's own submodule. Yes if you create classes that are common to more than one of your plugins, they can be defined at the 2nd level, directly under Tomot, and they ALSO can be removed and reloaded because the name of a Class, is also a constant (just as a module identifier is.)

                                          Top Level modules and classes (which should only be the Ruby base classes and modules,) cannot be removed (by design.)

                                          Now this will not solve ALL of the challenges with SU API developement, because many objects are really C++ objects and cannot be garbage collected by Ruby. But we can reduce many of the problems, by at least coding on the Ruby side, in the proper Ruby way.
                                          There have been many discussions in the forum on unattaching and 'cleaning up' observers.

                                          As far as reloading SU. Sometimes it just must be done, especially if your working with menus. We cannot at present remove menu items.
                                          To make things faster, in development, I have a bare-bones Sketchup copy with minimal development plugins only (and the DC extension,) that loads fast. On Windows, we can run Sketchup differently, by using extra user accounts, and using RunAs.. to access these differnt setups from the main user account.
                                          See my posts Saving multiple workspaces (and run batch file from ruby as admistrator perhaps if you wanted to use a batchfile and icons.)

                                          Now.. I agree with you and others, it would be great to have a good bridge between Ruby GC and C++ GC (if that's what it's called in C++.) So that things get cleaned on both sides when no longer in use.

                                          I'm not here much anymore.

                                          1 Reply Last reply Reply Quote 0
                                          • 1
                                          • 2
                                          • 3
                                          • 2 / 3
                                          • First post
                                            Last post
                                          Buy SketchPlus
                                          Buy SUbD
                                          Buy WrapR
                                          Buy eBook
                                          Buy Modelur
                                          Buy Vertex Tools
                                          Buy SketchCuisine
                                          Buy FormFonts

                                          Advertisement