Observers WhishList

[Dan Rathbun]

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

[tomot]

Dan: Thank you for your detailed explanation. Early on when I first looked at Ruby scripting, I knew nothing about Ruby and I still know very little. Many of the examples I used were from donated scripts, from which I borrowed and referenced code to develop my own self taught scripts, there were no module examples to speak or copy from. Its easy to see why not more people get engaged with Ruby.
To a novice trying to make sense of the current SU Ruby API descriptions and examples, is like shining a light on a subject without a battery in the flashlight.

[Dan Rathbun]

@tomot said:

Many of the examples I used were from donated scripts, from which I borrowed and referenced code to develop my own self taught scripts, there were no module examples to speak or copy from.

See this thread at GoogleGroups, begining with post 4, in which Harald asks the question "... so, are all my .rb scripts really just one huge script?"
He was having trouble with the Ruby environment getting corrupted with classes, objects, methods and so forth.. that he didn't want loaded.
Read my detailed responces, which explain how things get loaded (both in Sketchup Ruby, and Ruby in general,) and an example of file spanning.

[thomthom]

Unfortunately, the Google examples does not encapsulate their code. But you'll find most plugins here at SCF are. Usually it's the older ones that doesn't.
The norm is encapsulate the script in a module which is prefixed with your initials - that goes a long way to prevent namespace collisions. I use TT_, Jim use JF_, Chris use Clf_, etc.

[thomthom]

@tomot said:

To a novice trying to make sense of the current SU Ruby API descriptions and examples, is like shining a light on a subject without a battery in the flashlight.

Yea - - that description sounds just about right.

[PurpLev]

+1 for EntityObserver currently it's pretty much unusable as it crashes SU when it intercepts anything and tries to perform more than a single printout to the console.

[kwalkerman]

I definitely add my vote for an onBeforeSave for the Model Observer. Right now, I am doing some stuff and then re-saving...

A few things I came across:

1. re-saving triggers the onSave method in your application, and in any other plugins that have a Model Observer. This can lead to an annoying infinite loop. I fixed this problem by requiring that the times between saves be greater than a certain set time.

2. Once you re-save your model, the model observer immediately calls the onSave method. This means that any code below Sketchup.active_model.save "my model.skp" will not be executed until after the onSave is called and executed again... so any infinite loop prevention should be above the save command.

--
Karen

[Aerilius]

When hiding a layer that contains selected entities, these entities get un-selected. This seems not to trigger onSelectionBulkChange (or even onSelectionCleared).

[Dan Rathbun]

The SelectionObserver still seems to be the most problematic of all the observers.
http://www.thomthom.net/software/sketchup/observers/#note_SelectionObserver

[havanasud]

Hi, ViewObserver works on mac?

[thomthom]

@havanasud said:

Hi, ViewObserver works on mac?

Hi

Are you experiencing any problems or unforeseen behavior?

I've not heard of any issues. Think I've used it a couple of times and so far not received any reports of issues.

http://www.thomthom.net/software/sketchup/observers/#ViewObserver (Note - not everything here is tested. So if you find an issue, please let me know so I can update the chart.)

[glro]

onCopyElement

an observer that would detect when something is being copied

i have not find anything doing that among the existing obsersers

[thomthom]

Would that be at the event of copying? Or when pasting?
Can you describe the scenario you'd use it in?

[glro]

@thomthom said:

Would that be at the event of copying? Or when pasting?
Can you describe the scenario you'd use it in?

when copying
i am trying to find a way to control the difusion of dynamic components
if such an observer would be available, it would be easy to prevent unauthorized copies
selection observer can be used, but it is less direct, and probably less efficient than an observer on copying
more dynamic components would be created if there was a way to crypt them, just as ruby plugins