TIGs LayerWatcher

LayerWatcher [when prperly activated!] also has a context-menu item to set the Layer of ALL selected Edges/Faces to Layer0.
IF the selection includes ‘containers’ [Groups or Component-Instances] you are prompted to ALSO fix the Layers of any nested geometry…

So you can set Layer- to EVERYTHING that is selected that way…

I uninstalled LayerWatcher, restarted SketchUp, reinstalled LayerWatcher opened my model and still don’t get the warning when I click the circle. This was done through Windows-Preferences.

FYI, LayerWatcher’s active layer observer doesn’t fire for me unless I reload the code manually. I have verified that the extension is checked in preferences, policy is “unrestricted”, and restarted SketchUp. I’m coming to believe that some other extension is interfering, probably one that loads after LayerWatcher since manually loading the code via Ruby Console turns the observer on. But so far I haven’t figured out what it is.

Very odd.:pensive:
It works fine for me and many others.
I can’t think that another extension is interfering…
When you manually load it do you load the extension 'RB of the code file within its subfolder ?

Do you have v6.0 ?
[as reported in the Extension listing]

Can PC users [with these issues] close SketchUp and then open their Registry with Regedit and see what ‘TIG-LayerWatcher’ is set to in:
HKEY_CURRENT_USER\SOFTWARE\SketchUp\SketchUp 2016\Extensions
Vary the SUp version number as appropriate.
My ‘TIG-LayerWatcher’ is set to ‘1
Showing it’s active.
If it’s ‘0’ it shows it’s inactive.

When restarting SketchUp [but before manually activating LayerWatcher] can you also use this in the Ruby Console:
TIG::LayerWatcher::EXT
To see if it is being created - it should be if it’s getting listed !
And then:
TIG::LayerWatcher::EXT.loaded?
Which should be true if it’s being loaded…
Then:
TIG::LayerWatcher::EXT.load_on_start?
Which should also be true of it loaded as SketchUp starts.

All Observer clashes are inherently difficult to track down, but…
What other extensions might you have loading later on which affect Layers using Observers ??
Does anything else break when you manually activate LayerWatcher ???

For whatever it is worth, I’m on a Mac.

To make it work, I need to load the TIG-LayerWatcher_main_code.rb from the Data folder. It produces a lot of warnings in the Ruby Console about constants that were already defined, which is why I think it loads but something interferes.

Yes.

Returns a SketchupExtension instance

Returns true

Returns true

I’m truly baffled. All seems well, yet the observer doesn’t fire!

I’m unsure: do the extensions load in alphabetical order of the base .rb file names?

(BTW: I’m fanatical about Layer0 in my own models. I only run into issues in files shared by others)

Doesn’t the TIG-LayerWatcher_code.rb file work ?
That loads the file from Data
Perhaps that’s the issue ?

If you copy+paste line this in the Ruby Console before a manual-load fix, what is listed.

puts; $".each{|e| next unless e=~/LayerWatcher/;puts e;puts };puts

Plugins should load in alphanumeric order !#0-9A-Z
But if you have more that one Plugins folder set up, then each loads its files in turn, depending on the order they have in $:

Once again, all looks right…

/Users/steve/Library/Application Support/SketchUp 2016/SketchUp/Plugins/TIG-LayerWatcher/Data/TIG-LayerWatcher_main_code.rb

/Users/steve/Library/Application Support/SketchUp 2016/SketchUp/Plugins/TIG-LayerWatcher/TIG-LayerWatcher_code.rb

/Users/steve/Library/Application Support/SketchUp 2016/SketchUp/Plugins/TIG-LayerWatcher.rb

Yep, all are loading…
I have been intending to simplify the loading anyway, so v7.0 will be signed and published at the SketchUcation PluginStore soon…
Please try that and see if it helps…

SketchUp Plugins | PluginStore | SketchUcation is now v7.0… with a simpler loading regime that might help ?
Please get and retry…

I tracked it down! When the app initially loads on my Mac the LayersObserver#onCurrentLayerChanged callback is finding that model.active_tool.name is “RubyTool” so it is bailing out without doing anything! If I explicitly select any built-in tool before changing the active layer, your trap works.

I’m not sure whether this is a Mac SketchUp bug (i.e. bad initial state) or whether a later loading plugin is selecting a tool (the only things loading after TIG stuff are TT stuff!).

Same results with v7.0, but see my other post. It seems to be an issue with initial state of the app on Mac.

Edit: more info. It is definitely interference from some other extension/plugin that activates a tool on load. I set up a sterile install with TIG-LayerWatcher the only thing in Plugins, and it works just fine. So (ugh) the task is now tracking down the guilty party in the somewhat excessive suite of extensions I have active!

I tried both for the first time and I do see the warning in v7…

however both versions caused BugSplats when using undo… [@Barry I submitted them]

even on models I haven’t used it on after an SU restart…

there’s some observer issue with LayerWatcher on my mac at least…

john

My registry shows ‘TIG-LayerWatcher’ is set to ‘1’ with version 6 and again with version 7,

Now with version 7 LayerWatcher does not fire the warning with any of my models, will reinstall V6 and report.

Now with Version 6 or 7, the registry shows active (‘1’) and LW doesn’t fire with any of my models.

Let me go through the reinstall process that I did. From the SketchUcation Extensions Manager (v3.0.0) I selected TIG-LayerWatcher and clicked the Disable button I also unchecked the TIG-LayerWatcher check box from System Preferences and received the message to restart SU to complete the process, which I did. On restarting TIG-LayerWatcher is unchecked in System Preferences and in the disabled column. Then from System Preferences, clicked the Install Extensions button and selected TIG-LayerWatcher_v7.0.rbz and was told it was installed and ready to go. Highlighting it in System Preferences shows it as version 6, SketchUcation Extensions Manager (v3.0.0) has it in the disabled column and shows it as version 6. Restarted SU again, System Preferences has it active and as V7, as does SketchUcation Extensions Manager (v3.0.0).

I’ll look into this further.
The reason LayerWatcher doesn’t kick in if the active-layer is reset inside some Ruby code is that it might break that plugin.
One example of this is SUp’s own poorly written ACTs !

But of course it should still be set up and wait for you to try and change the active-layer whilst using native-tools…

@john_drivenupthewall what’s the MAC SUp version and what type of splat ?

Its ‘operations’ are nested so undo’s occur in the current context NOT the LayerWatcher’s operation ?

I’d of course appreciate any investigation results from you all…

Sketchup.version
16.0.19913

the splats are fast, i.e. no ‘beach balling’ and occur when you would normally reach the ‘zoom tool’ if using ⌘z to undo…

it first happened in v6 after I ‘fixed’ the test file and then added geometry to a ‘wrong’ layer to test for the warning…

after, testing that, I used ⌘z to step back and re-test, instant ‘BugSplat’ with report dialog when I got to the step which had moved all the geometry to layer0… [i.e. your plugins action]

I restarted and went on working on something else, but needed to undo all the changes, so just used repeated ⌘z, as I do normally, but it splatted again after the last real undo…

then I saw your v7 and installed it, opened the same test file and saw the warnings were now working…

carried on and test the ‘undo’ and it again splattered…

opened a new file, drew some geometry, used ‘undo’ and it also splattered…

no layers were added or moved for this to happen, and disabling LW resolves the issue with ‘undo’ terminating at the ‘zoom tool’…

I think I submitted one splat from each version, so someone could have a look…

john

I haven’t been able to reproduce John’s splats on my Mac. I temporarily worked around the active tool issue by creating a zzzzzzz.rb file (so it loads last) that just activates the selection tool. With this going, the LayersWatcher detects changes in Active layer right from the start.

I wish SketchUp let you attach names to Ruby extension Tools so that one could tell what is active! “RubyTool” isn’t very helpful, and the tool id is opaque.

@slbaumgartner On a PC the active tool at startup is initially set to Select.
Isn’t it on a MAC ?
I’m not near a MAC to test this…
Maybe some other loading plugin is resetting the active tool to ‘nil’ ?
@john_drivenupthewall The reassigning of layers etc is done in a nested operation, so when you undo say drawing a line on another layer, the LW code which moved it to Layer0 should be encapsulated in the same undo block as the line.
Perhaps it’s different on a MAC ?
Although Steve can’t replicated Johns splats !

Perhaps thomthom or some other API guru has ideas from the submitted splat-reports.
But we’ll have to wait until they come back in the new year…

I believe it is supposed to be (and is if I disable all extensions), but on my Mac some RubyTool is selected on startup. Still trying to figure out what it is (the fact that Ruby Tools can’t be named doesn’t help!).

On a MAC can you use the Terminal window and try something like:
cd path_to_plugins_folder find -name '*.rb' | grep .tools
To find RB any files referencing the model’s tools ?