[Talk] Plugins Quarantine

thomthom

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 example

I don't think I want this banned though - but a clear warning should be issued about it in the way it invades the SketchUp environment - and do make changes to base classes.

chrisglasier

@jim said:

For disussions related to the Plugins Quarantine area.

Questions, comments, suggestions, and insults accepted.

You have helped me a great deal in the past not only to appreciate a rational approach to software but also to speak out if something seems wrong. I am grateful for that. This quarantine idea is terrible.

You really want to introduce a new human system with lists and banning when surely the goal is self-organising non-human systems that neither censure nor inhibit human endeavour (here, in developing plugins) rather support it. Like WWW.

If there is a conflict of names the last to be loaded will prevail. So isn't the trick to load the code every time a plug in is selected. This would be the job of the system loader. It is for the developer to ensure there is no conflict within his own coding and its included files; in this respect the multi-level namespaces/modules are most useful. (But these can never be the ultimate global defense because they rely on human choice.)

I just saw TT's note about altering base classes. That is a problem when these have not been uniquely pre-fixed/identified and reserved. I don't have a solution ... perhaps some kind of filtering/renaming in the loader ... but I know banning is not a workable/acceptable solution for this era.

Dave R

Unfortunately there are a few plugins out there that wreak havoc with other plugins because these scripts change base classes. They cause no end of trouble for users as evidenced by the repeated requests for assistance in getting other plugins to run and the solution being to disable these troublesome plugins. the authors have been asked multiple times to fix their scripts but so far have not done so. It seems to me that if authors won't take the needed steps to make their scripts play nicely, they should not be hosted here on SCF.

thomthom

@chrisglasier said:

If there is a conflict of names the last to be loaded will prevail. So isn't the trick to load the code every time a plug in is selected. This would be the job of the system loader. It is for the developer to ensure there is no conflict within his own coding and its included files; in this respect the multi-level namespaces/modules are most useful. (But these can never be the ultimate global defense because they rely on human choice.)

That sounds complicated and open to any kind of bugs and unforeseen issues.

SketchUp has a shared environment where all plugins reside in. Because of that it is each developer's responsibility to ensure they encapsulate everything to avoid clashes. What base classes and modules that ships with SketchUp should also not be altered as it would be exactly the same as messing about in the global namespace.
Now, it would be great if plugins automatically was unable to interfere with each other, though it would also bring on limitations in terms of extensibility. But the reality is what it is - we need to deal with it as is and not in some utopic theoretic manner.

We're spending a great amount of time on some very few plugins that cause problems. And personally, and many other of the mods here, we try to inspect plugins from new plugin writers and spot for potential issues. We then present this to the author with explanations and suggestions for alternatives. But some times the author never responds - and we just end up wasting a great amount of time.

I therefore support this list and the removal of plugins where the author does not amend the offending plugin. It's not for shame, but a mean for us (developers, moderators and users) to be able to log and track known issues and conflict. The amount of wasted time trying to repeatedly resolve these conflicts is ridiculous and I'm fed up with it!

If you got alternative ideas, then by all means, do share it. But please let it be practical and pragmatic dealing with the reality of the current situation.

TIG

Let's be pragmatic!

Here's my partial list - mainly for ill-advised base-class 'fiddling' etc... which mess up other legit tools using the proper API...

SketchyPhysics [PM'd author several times]
DrivingDimensions [PM'd author several times]
SunStudy/SunTools/SolarStudy/SolarPosition or whatever it's called [seems to be defunct]
Matchbox [seems to be defunct]
VirtualWind [overwrites default progressbar! fixes published by others, but not ideal that the base tool is pants!]
Podium [some versions : ] [but this seems to be superseded ] And several toolbar compilations that include out-of-date scripts [from 3rd parties that might have not always been included with any kind of 'permission' from their authors], and more worryingly out of date 'system' files - like sketchup.rb and extensions.rb - which the main Sketchup installer will have already put afresh into the Tools folder - but this compilations might have placed old versions into the Plugins folder... where of course they'll get found by the startup auto-loader before the legit versions in Tools ! This is subtle in its effects and often difficult to trace...

Also there have been some recent half-baked 'BIM/BAM/BOM' toolsets that although they are changing almost daily per update... they currently do seem to reset [to suit their own devices as they load] things like 'current-view', 'camera-type', 'on-layers', etc - applied to every SKP that a hapless user opens, this is rather than as the user chooses to initialize/use them... [its IS solvable by tagging any such BIM SKP as such with an attribute, so that they only open in a 'BIM' way]

I think the onus needs to pass back to all of these authors, who have to date left us to clean up the crap left in the trail of their illegitimate offspring...

If authors publish 'dangerous' stuff we must warn others about it, and if necessary remove it from SCF threads and links... because we spend a lot of time sorting out new users who stumble into traps these ill-advised tools create - albeit done unthinkingly...

Humpmetwice

I've had problems with the ModelFunction plugin.

chrisglasier

@thomthom said:

... we need to deal with it as is and not in some utopic theoretic manner.

I thought this kind of Luddite attitude had faded ever since we learned Englebart, Gates, Berners-Lee had faced the same charge.

@thomthom said:

That sounds complicated and open to any kind of bugs and unforeseen issues.
SketchUp has a shared environment where all plugins reside in.

Well it isn't at least in JavaScript. After all I am only suggesting rearranging the same environment on selection of a plugin.

@unknownuser said:

Because of that it is each developer's responsibility to ensure they encapsulate everything to avoid clashes.

Now that does not work because you are involving human policing. Anyone can create a website. If they don't follow the language rules it won't work. It will never compromise any other website as far as I know. The existing Sketchup plugin system should be modified for the same ends.

@unknownuser said:

If you got alternative ideas, then by all means, do share it. But please let it be practical and pragmatic dealing with the reality of the current situation.

Be careful with remarks like that!
(Toffler:"Idea-assassins rush forward to kill any new suggestion on the grounds of its impracticality, while defending whatever now exists as practical, no matter how absurd.")

Krisidious

I just like having a warning. And truth be told if the creator knew there was a problem then he/she probably wouldn't have released it. others see things from a different perspective and see the mistake you miss. and let's face it we have some of the foremost sketchup developers on the planet. when they look at a noob's plugin they see every hair that's out of place.

I like the idea better of a review board and or SCF approval or review board approval. then people would add their work to some submission area where everyone would look at it in their respective test installations, then if it passes muster it is added to then SCF plugin index of approved plugins. and they could advertise with some icon as such. then I could just look for the approved icon and know I'm safe.

of course who would reward this panel? this review board? as it is now Thom and Tig and some others pour over newly released plugins and warn us and the developer of errors or conflicts. while a great service to the community, these few individuals get nothing but knowledge and thanks in return.

But you know... I don't make these things and I'm very grateful to everyone who does... The last thing I want to do is de-incentivize the creators.

as you were.

thomthom

@chrisglasier said:

@thomthom said:

That sounds complicated and open to any kind of bugs and unforeseen issues.
SketchUp has a shared environment where all plugins reside in.

Well it isn't at least in JavaScript. After all I am only suggesting rearranging the same environment on selection of a plugin.

Javascript, WebDialogs, yes. They are isolated. In SketchUp Ruby API, no - is is shared. How do we deal with that? I cannot rewrite Ruby and SketchUp to make it work completely different from how it is designed. Do you have concrete samples of actions that could be done based in the status quo?

@chrisglasier said:

@unknownuser said:

Because of that it is each developer's responsibility to ensure they encapsulate everything to avoid clashes.

Now that does not work because you are involving human policing. Anyone can create a website. If they don't follow the language rules it won't work. It will never compromise any other website as far as I know. The existing Sketchup plugin system should be modified for the same ends.

Again - the same as above. Websites are isolated entities. SketchUp plugins are not! Oranges and apples.
The reality is that the environment is shared. We must deal with that - it's what we've been doing here for a long time and it's wasting a lot of time. Since it is shared there must be some human policing. Developers must take responsibility.

@krisidious said:

I like the idea better of a review board and or SCF approval or review board approval. then people would add their work to some submission area where everyone would look at it in their respective test installations, then if it passes muster it is added to then SCF plugin index of approved plugins. and they could advertise with some icon as such. then I could just look for the approved icon and know I'm safe.

of course who would reward this panel? this review board? as it is now Thom and Tig and some others pour over newly released plugins and warn us and the developer of errors or conflicts. while a great service to the community, these few individuals get nothing but knowledge and thanks in return.

That wouldn't make any less work for us - having to moderate every plugins there is. I want to educate, not police. I will not be on such a board.

The bottom line is:
Most plugins do work nicely with each other. It's just a very few sets that's causing trouble. But these few is causing a lot of extra work for other developers who get support request, and a lot of work for us moderators. We do realise that new developers might not know how the SketchUp plugin ecosystem works and we do provide feedback. But when this feedback is ignored, what are we to do?

chrisglasier

@TT

As usual I failed to expose essential details behind my proposal. Simply though the applications I have made using JavaScript have a core section which provides the basic mechanism to manipulate raw data and individual devices which make different types of multimedia displays from it. The devices could be loaded all at once to create a situation similar to an environment of Sketchup plugins.

Many of my devices have a start() function so the last one loaded is always current. To ensure the right start function matches the selected device I have its file reloaded after the device has been selected. I don't know if that can be done in Ruby. If so I think the comparison is valid.

Any devices with any function prefixed core will not work. Couldn't this be applied to core Sketchup as part of Trimble's application?

Just ideas ...

thomthom

@chrisglasier said:

Any devices with any function prefixed core will not work. Couldn't this be applied to core Sketchup as part of Trimble's application?

That would be something the SketchUp devs would have to do. We cannot modify the SketchUp core. A more robust plugin environment, even a sandbox feature authors can opt in for would be nice. But it's a SketchUp feature request, which is another topic all together. What can we do right now, as is? Today, or this week?

chrisglasier

@thomthom said:

@chrisglasier said:

Any devices with any function prefixed core will not work. Couldn't this be applied to core Sketchup as part of Trimble's application?

That would be something the SketchUp devs would have to do. We cannot modify the SketchUp core. A more robust plugin environment, even a sandbox feature authors can opt in for would be nice. But it's a SketchUp feature request, which is another topic all together. What can we do right now, as is? Today, or this week?

Well I could draft the request if you and the others agree to check it and endorse it ... in a new topic of course.

thomthom

Sure. Got my thumbs up for that.
I just wanted to keep this topic in the lines of what we can act on now. Not something we'll have to wait for any potential future release a few years ahead into the future. Because right now we spend hours every week on these issues.

micione

I'm sorry,
I am not an expert on the subject.
But I would like to ask a question: TIG, Thomthom, it would be possible to create a plugin (also not free) that "reads" the other plugins? To find out if you try to change the class-base, etc..
I realize that they must not be easy, but You are true professionals.

thomthom

There are so many ways base classes can be expanded - but one could perhaps catch the most common ones...

Aerilius

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.

TIG

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

Aerilius

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

thomthom

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

TIG

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