[Plugin] TT_Lib²

TIG

When an Extension 'sticks' in the disabled [red] side of the Manager despite you trying to enable it, then it means that something is wrong with its code as it loads...

Have you ever disabled this Lib ?
Are you sure it is installed correctly ?

Look at the files inside the Plugins folder.
If they are named ending in .rb! they manually rename them as .rb and restart SketchUp.
You should now see an error message.
This might help resolve what is wrong.

If you have FULL rights to your Plugins folder and have installed the very latest versions of the Lib and other related Plugins, then there should not be any odd behavior

tt_su

Maybe the PluginStore is confused over the root TT_Lib2.rb file. It implements SketchupExtension class - it it appear in the Window > Preferences > Extensions list. But unticking it won't disable TT_Lib2 because the plugins that use it load TT_Lib2/core.rb directly.

I still don't know if that is the case though, I don't know what PluginStore is doing.

When TT_Lib2 appear disabled in PluginStore - do the plugins that depend on it load?

TIG

@TT - your Lib appears in the native Extensions panel and the SketchUcation Extensions Manager.
But it fails to display details in the latter - I suspect because you've named it with a superscript 2 - because if I rename it with a normal 2 it works with details etc !
So that is probably causing subtle issues - perhaps in js ?

So I know how to probably fix the issue - I'm testing it shortly...

Watch for v2.5.0 out soon...

tt_su

Ah, an multi-byte character issue then.

TIG

I now have it working with the superscript 2...

tt_su

Thanks TIG!

That superscript 2 has caught many off guard.

"Nobody expects Unicode multi-byte characters!"

TIG

Oddly the superscript 3 in your 'Cleanup' name works just fine.
It's only seems to be the superscript 2 !
But then even 178.chr fails too...

I already knew that names including a ' or starting with '#' messed up in the ruby/js/callbacks...

I have also now found that names ending in a <space> also mess up !

But they are all trapped now.

tt_su

huh! That's very odd, as I'm sure that superscript 3 is in unicode as well... :s

TIG

Tell me about it...

The characters in Extension names that mess with ruby/js/callbacks in webdialogs when passing js-side RS joined [RS = String.fromCharCode(30)] arrays, that are then then split at RS [RS = 30.chr] ruby-side, to give the individual names, are:

[pre:1yxha6nn]<space> at the end of the name

at the start of the name

' [single-quote] anywhere in the name
² anywhere in the name[/pre:1yxha6nn]

It doesn't matter if that is Unicode or ASCII 178.chr
Other superscripts etc like ³ do not seem to cause issues at all...

I have a series of traps to stop issues now - these will be in an upcoming release [aka 2.5.0]...

Oxer

In the end, you have found the problem of TT_Lib² in Extension Manager

TIG

@oxer said:

In the end, you have found the problem of TT_Lib² in Extension Manager

You can still manipulate that Lib [for now] in the native Extensions panel.
I'd always leave it 'enabled' anyway...
A new version of the SketchUcation Toolset, including the updated Extensions Manager and lots of new goodies, is in alpha-testing now - sliding into beta-tesing soon - and then v2.5.0 will be released - probably early in the new year ?

TIG

Now the bad news...

After further testing... I confirm that my fix for a superscript 2 in the Extension's name doesn't work with TT_Lib² after all... It was a spurious result...

It must be something to do with the way the file calls itself - almost unique amongst Extensions !
Then I noticed that Fredo's Lib uses a fake Extenson...

#Compatibility with EWH begin ; SketchupExtension.new "toto", "toto.rb" ; rescue ; end

That is all, and that gets past the EWH check and does NOT register an Extension ?
Although through other means there is an entry fro LibFredo6 ?? ...

So the fix seems to be in TT's hands.

Simply remove the current 'extension making code' and add in a 'fake file' like as shown above, and it works... there's no 'fake extension' confusing users in the Preferences OR the SCF Extensions Manager...

tt_su

That's odd. How is PluginStore determining if a plugin is enabled/disabled?

By the way, are you doing string manipulations? Passing a Ruby multibyte string, encoded in UTF-8, should work fine as long as the HTML is marked up in UTF-8 as well. JS handles UTF-8 by default I think as well. So simply passing strings back and forth should not be a problem.

TIG

HTML is UTF-8 - there is no issue the superscript 2 was a dead end...

The Extensions Manager uses the obvious :

` Sketchup.extensions.each{|ex|
next unless ex.respond_to?(:registered?) && ex.registered?
...
if ex.loaded?
...
else ### unloaded
...
end

}`

etc

Fredo's Lib uses the spurious file ans has no issues.
Calling itself seems to break it.
I substituted the equivalent of Fredo's one liner in your 'loader, it doesn't register an extension BUT it does still let the Lib be used...

thomthom

Updated TT_Lib 2.9.5 will fix the issue.
Download from PluginStore or BitBucket:
http://sketchucation.com/resources/pluginstore?pln=TT_Lib
https://bitbucket.org/thomthom/tt-library-2/downloads

Submitted to moderation on Extension Warehouse.

This should address 3D Text Editor's issue with IE11 and hopefully appear correct to PluginStore.

Oxer

Thanks Thom for fix the problem!!

TIG

The update does fix the 3d text font list problem...

BUT...

On PC and MAC I now get this issue whenever SketchUp starts
@unknownuser said:

Error Loading File C:/Program Files/SketchUp/SketchUp 2013/Plugins/TT_Lib2/core.rb
uninitialized constant TT::System
Error Loading File TT_Lib2.rb
uninitialized constant TT::System
One step forward one back.

Also you have not fixed the issue of a 'mock Extension' like your Lib calling its own file, which breaks the listing in the SketchUcation 'Extensions Manager' dialog, where it always appears disabled, even though it is enabled.
As I explained before... Fredo gets around it by loading a non-existent 'toto.rb' file in a begin...rescue, and NOT registering it at all, which means an spurious Extension is not listed - so it should not appear in the Extensions list ?
You have now stopped it calling itself, BUT now load [and register] 'core.rb', which exists in the Lib's folder, but that now creates errors too... why not put it in a 'begin...rescue' block and refer it to a file you DON'T have in your TT_Lib2 folder - like 'foobar.rb' - and do NOT register it, then no Extension is made and no one is confused at all...
This edited code works for me

### EXTENSION ### ------------------------------------------------------------
  
  unless file_loaded?( __FILE__ )
    # This library is still loaded by plugins because they require
    # 'TT_Lib2/core.rb' directly. 
	# Disabling the library via the extension manager 
	# will have no effect on the dependant extensions.
    #
    # The purpose of this file is solely to make it compatible with the
    # Extension Warehouse policies.
    file_loaded( __FILE__ )
	begin
		ex = SketchupExtension.new( PLUGIN_NAME, 'TT_Lib2/foobar.rb' )
		#ex.description = 'Library of shared functions used by other extensions.'
		#ex.version     = PLUGIN_VERSION
		#ex.copyright   = 'Thomas Thomassen © 2010-2013'
		#ex.creator     = 'Thomas Thomassen (thomas@thomthom.net)'
		#Sketchup.register_extension( ex, true )
	rescue
	end
  end

the Lib is loaded by other tools, it is NOT made into an Extension, so there is NO confusion at all...

tt_su

@tig said:

Also you have not fixed the issue of a 'mock Extension' like your Lib calling its own file, which breaks the listing in the SketchUcation 'Extensions Manager' dialog, where it always appears disabled, even though it is enabled.

Huh? I changed to to load core.rb ...

I didn't want to use a dummy file as I wouldn't trust that to not display an error.

thomthom

@tig said:

You have now stopped it calling itself, BUT now load [and register] 'core.rb', which exists in the Lib's folder, but that now creates errors too... why not put it in a 'begin...rescue' block and refer it to a file you DON'T have in your TT_Lib2 folder - like 'foobar.rb' - and do NOT register it, then no Extension is made and no one is confused at all...

The real fix here is to figure out where the error is coming from. I don't want to patch the symptom, I want to fix the cause.

thomthom

I'm not able to reproduce the TT::System loading error...