[Talk] Plugins Quarantine
-
If there's no decision taken about total removal of such scripts, one could add a tag to the plugin post's title that is considered by the plugin index script.
-
@thomthom said:
There are so many ways base classes can be expanded - but one could perhaps catch the most common ones...
and... since no one pays us to do this, then it's a balance between us fixing the problems as they arise in users' posts, versus us writing a tool to fix problems, that were created by others and which they ought to fix themselves...Fellow members... please don't get us wrong here... this kind of problem is NOT widespread...
There were some scripts a while ago that overwrote base-classes etc and messed up others' legit tools - these are now rarer. - but several of them are 'popular' and still carry the tainted code - but as they are 'old' the authors show no urgency in resolving these problems...
There are some toolbar compilations that bundle 'old system files' and install them in the wrong folders etc - again these are somewhat old tools and could readily be fixed, had the authors got the will, but because these are 'old' they show little urgency...
Some recent 'BIM/BAM/BOM' tools are 'in beta' and so they are somewhat half-baked. These can currently change the setting of any model the user opens, without the user's knowledge or prior consent... Again this can be fixed so that the changes only apply to SKPs where the user chooses to make them into 'BIM' SKPs... This needs fixing before the tools are 'safe'...
Moderators spend disproportionate time fixing these issue, so we are looking at ways of stopping them happening...
The other disproportionate 'time-waster' is the [usually-new] users who can't read/understand simple instructions and download/install/activate relatively simple sets of files+helpers without getting error messages... We are also discussing how we might reduce the 'failure-rate' -
@unknownuser said:
but several of them are 'popular' and still carry the tainted code - but as they are 'old' the authors show no urgency in resolving these problems...
Forking&fixing (if license allows) and taking the original offline then. I know it's not our job. Or just taking them offline. Or we just add a warning but then the status quo doesn't change because there are users who don't remember from where they downloaded software or don't remember having seen such a warning.
Also a problem is that they are still distributed over other ways/websites where plugins are never updated.@unknownuser said:
users who can't read/understand simple instructions and download/install/activate relatively simple sets of files
That is something Trimble/SketchUp should fix. A plugin installer plugin works only for users who are able to install that.
-
@aerilius said:
A plugin installer plugin works only for users who are able to install that.
There is the Install Extension features of SU8M1... but it doesn't seem to be much used.
-
If your Simple-Plugin-Installer came as a RBZ file then if they have >=v8M2 it will put the file into 'Plugins' - it's pointless them doing it manually as it needs that version to work anyway... The instructions can be relatively clear and simple...
Although, if they can't install a single .rb file into the right Plugins folder etc then they ought to be barred from using a computer anyway
After your tool is installed then they can use that tool to install all future tools in RBZ/ZIP/RB/RBS formats... -
Offtopic: I'm thinking whether one could include code to validate an installation and to fail gracefully in any case no matter how wrong a user messed up the files.
But that doesn't help for other plugins.
-
@tig said:
If your Simple-Plugin-Installer came as a RBZ file then if they have >=v8M2 it will put the file into 'Plugins' - it's pointless them doing it manually as it needs that version to work anyway...
True, it would work better as a repackaged RBZ, with step by step screenshots of installing via Extensions.
-
Hi everyone. Interesting discussion; thanks for the feedback.
First I will say that I know the title "Plugins Quarantine" is a bit of hyperbole. The purpose of the quarantine is simply a resource to keep track of plugins that are behaving badly to help in trouble-shooting plugin problems. With the list in place, we can point user to the topic and say "remove these plugins if you have them installed." And with a warning message close to the download in the original plugin thread, hopefully fewer people will be tempted to install.
I am not planning on removing any but the most offensive plugins. The Matchbox plugin redefines the behavior of Array concatenation in SketchUp-Ruby. Arrays are probably the single most used data structure in Ruby and nearly every single plugin uses them. This is the problem - a single plugin can redefine the behavior of a built-in function that every other plugin relies on.
Note that with Matchbox, I only moved the download from the Plugins forum to the Quarantine post. The download is still available, and it has been downloaded 4 times since being moved in spite of the warnings!
@unknownuser said:
For my part Sketchyphysics make some troubles with some of other plugins
So use it only when you need it else rename Sketchyphysics.rb in rbo for exampleThis is a problem. SketchyPhysics is a great plugin, but the implementation needs improvement. I have attempted to message the author of SP, but have not had any reply. It will be quarantined until the code is cleaned up.
@aerilius said:
If there's no decision taken about total removal of such scripts, one could add a tag to the plugin post's title that is considered by the plugin index script.
I've considered this, and like the idea of an extra warning tag in the plugins index. It might happen.
Thomthom proposed there should be 2 quarantine levels - warnings and bannings. I agree. Bannings will be reserved for the worst of the worst. Most plugins will just get a warning. After all if we erase the download, we also erase the possibility for anyone to download the code in order to fix it.
-
I think the Matchbox plugin is so bad it should be wiped of the face of the digital earth. Really - as you say it's been downloaded several times already within a thread strongly warning about it. I say we remove this dead horse so people don't poke it.
-
Also, I may set a date of "SketchUp 9" for banning any remaining troublesome plugins. That will be a good opportunity for users to cleanup their plugins folder.
-
I agree that Matchbox and SunPosition [?] should "disappear" - they have no merit that counteracts their problems.
SketchyPhysics has it's fan-base, but is a problem with base-class fiddling... so "warn!" and no 'support' to anyone who uses it.
DrivingDimensions is similar... BUT its author is arrogant and does nothing to fix the mess his tool makes, despite advisements... I say "strong warning!" and no 'support' [ever] to anyone who uses it. -
@tig said:
I agree that Matchbox and SunPosition [?] should "disappear" - they have no merit that counteracts their problems.
SketchyPhysics has it's fan-base, but is a problem with base-class fiddling... so "warn!" and no 'support' to anyone who uses it.
DrivingDimensions is similar... BUT its author is arrogant and does nothing to fix the mess his tool makes, despite advisements... I say "strong warning!" and no 'support' [ever] to anyone who uses it.Simply if the problem is base-class fiddling then the base-classes should be protected by design not dictum. Technical prowess not personal intervention.
-
Well... how are you going to 'protect' these Ruby base-classes from rogue authors' 'fiddling' ?
Even the very core base-classes like Array can be added to... or much much worse overwritten by 3rd party... Let alone the 'additional' Sketchup ones.'Looking' inside .rb scripts to find potential issues is limited because there are so many subtle ways of messing up base class/methods, and of course it's impossible with complied .rbs versions like DrivingDimensions !
I'd prefer 'personal' intervention [aka simply 'shunning' or 'forewarning-about' problem-scripts] to some draconian behemoth that polices the streets of Ruby like Judge Dread in the shadows... doling out 'justice'... for who watches the watchers ? ...
How exactly would you do this ?
-
@tig said:
How exactly would you do this ?
Well of course I am no expert but it seems to me that if any of the words used for classes, methods or whatever in the API appear in a plugin then that plugin should simply not work, unless of course the words were used inside a Module. This seems to follow what I see with JavaScript reserved words and duplicated words protected within different directories. If something like this were possible hopefully Sketchup would issue a free patch for their application.
Worth discussing don't you think?
-
Yes, but again - what can we do?
-
@thomthom said:
Yes, but again - what can we do?
Give http://forums.sketchucation.com/viewtopic.php?f=323&t=47388 a chance?
-
That's not what I mean - asking the SketchUp developers to change the core of Ruby. Even if that would happen - it wouldn't happen for a very long time.
I mean what can we actually do?
-
Your idea only works in plain coded .rb file, because compiled .rbs scripts are inaccessible...
So if some code contains the phraseSketchup::Group
you'd ban it - NO, because that occurs is many...is_a?(...)
test !
Yes... theclass Sketchup::Group
would be trappable, but what if it made a very unique new addition to the class's method, rather than rewrote an existing one [which should be stopped BUT who compiles the lists etc ?] or then... worse because it now clashed with a matching-named custom method made by another's script [which one gets precedence] ??
I can't see how this wold be manageable by 'us'.
Perhaps an 'obersturmfรผhrer' Sketchup-System tool could oversee it, but then I fear a 'terminator' rather that the marginally more preferable 'judge-dread' app... -
@thomthom said:
That's not what I mean - asking the SketchUp developers to change the core of Ruby. Even if that would happen - it wouldn't happen for a very long time.
I mean what can we actually do?
Assuming we can work out and agree a coherent request it may take sometime. But if we could market it on the grounds, say, that existing Trimble users will need new plug-ins for their specialist work; if it could be heavily promoted at the imminent base camp; it may have a chance to be treated as a separate enhancement of the core soon.
Just doing nothing just guarantees it will never happen.
Helping with this in the way I have proposed is really all I am capable of. Sorry.
-
@tig said:
Your idea only works in plain coded .rb file, because compiled .rbs scripts are inaccessible...
Doesn't checking get done on selection so the source is irrelevant. In JS the only checking of file content is done if you request validation.
@tig said:
So if some code contains the phrase
Sketchup::Group
you'd ban it - NO, because that occurs is many...is_a?(...)
test !
Yes... theclass Sketchup::Group
would be trappable, but what if it made a very unique new addition to the class's method, rather than rewrote an existing one [which should be stopped BUT who compiles the lists etc ?]I was just thinking of an uncomplicated search of the API for matching words - Alex's cheat sheets come to mind which Jim and I used to make an API machine.
@tig said:
or then... worse because it now clashed with a matching-named custom method made by another's script [which one gets precedence] ??
Well that's the second part of the request -
@unknownuser said:
... and accommodates any possible duplication of names between all plug-ins **.
...
**For example, one suggestion is to reload the .rb file of the selected plug-in so that it overwrites any duplicates.
@tig said:
I can't see how this wold be manageable by 'us'.
It should not be. In developing my own applications I accept that I need to be responsible for ensuring imported devices cannot clash.
@tig said:
Perhaps an 'obersturmfรผhrer' Sketchup-System tool could oversee it, but then I fear a 'terminator' rather that the marginally more preferable 'judge-dread' app...
Lost in the imagery!
Advertisement