Fredo's plugins not in Extension Warehouse...?
-
Am I right in saying this? If so why...?
-
It would seem so. I'm quite surprised, as he had updated his library files right from the start, to make sure that the extensions worked in V2013. I've been using JPP, TOS, Curviloft etc for weeks in the new version.
-
Fredo's tools usually need his Lib.
He updated that recently to address a few v2013 foibles...
However, the new EW has very draconian rules about a plugin being an Extension and how its loader.rb and associated support subfolder are named to match, and only those are allowed in the rbz etc.
Therefore, many authors will have to rewrite existing scripts to correspond.
This is not a simple task for many toolsets.
A new tool can usually be written to comply, but existing tools can have ingrained structures that are much more difficult to untangle.
By contrast the SketchUcation PluginStore http://sketchucation.com/resources/pluginstore has a much less rigid regime, and so it includes all of Fredo's latest updates and Lib - you can get the RBZs and manually install them...
Alternatively, the 'SketchUcation Plugin Store' tool http://sketchucation.com/resources/plugin-store-download is also easily downloaded and installed - that allows you to AutoInstall the PluginStore's contents from within SketchUp itself [Note: you'll probably need to restart SketchUp after updating the Lib, but thereafter AutoInstall of other plugins should install/load and make then immediately available without a restart].
There are literally hundreds of plugins that are not Extensions, or that would just be too much trouble to rework to be compliant for the EW: however, these are already available via one of the two SketchUcation PluginStore systems...
-
TIG,
That's exactly the point. Cosntraints on EWH are very drastic and I found that adapting my scripts requires significant work, especially in the details here and there, not including the update to documentation and posts on this forum. Ultimately, I will adapt the scripts however.
Now, let me formulate my own question?
Why Sketchucation's Plugin Store tool not in Extension Warehouse?
This would make sense, because, as highlighted by TIG, there would remain hundreds of scripts that won't be proper SU extension or comply with EWH rules. But these scripts could still be distributed via the Plugin Store.
Fredo
-
We did submit and it was refused.
-
@rich o brien said:
We did submit and it was refused.
Was it for 'technical' reasons? I guess not!
I really don't understand Trimble. Their interest is in selling Sketchup and showing its extensibility via numerous plugins supported by an active community of script writers who support them and add more every day.
Most plugins are free and Trimble does not have a competing activity of writing plugins as far as I know. I don't think either that they have an AppStore policy whereby they would take a small dime at each download.
So Trimble should not care about what are the sources of plugins since at the end, the more you have the more it makes Sketchup powerful and attractive. Having an organized and moderated source like Sketchucation, with good practices supported by a user and developer community, should even be seen as a more valuable source than other less managed places.
EWH and Sketchucatioon Plugin Store are both well designed and well integrated within Sketchup. EWH is more 'official' and constraining, Plugin Store is more user-friendly, more flexible for authors and it pays more attention to small important things like documentation and donation. But, many scripts will end up being on both distribution channels anyway.
So what is the point?
Fredo
-
It was obviously for 'political reasons'.
However, the 'SketchUcation Toolset' would be 'non-compliant' with EW anyway...
because its loader is named '!SketchUcation.rb' [to put it at the top of the Plugins menu list] and its folder is named 'SketchUcation' - so there's a naming mismatch...The EW rules pretty much pertain to them having the ability to 'uninstall' their EW extensions: because their tool will remove the loader rb [gettable in v2013 from the extension's methods] and any subfolder with it of the same name ! Thus every EW extension has to have its own loader and its own subfolder with the same name...
The main point is that many of the plugins now available at SCF will never become available at EW.
The EW rules are too restrictive and time consuming to address, and it's also limited to extensions.
But conversely there's nothing stopping any EW extension-plugin from appearing on the SketchUcation system with its author's consent... -
The only reason I can think of is that they are starting out as they mean to continue; and are laying the ground rules for authors of new scripts...perhaps from a background much wider than SketchUp's existing userbase. It might just be that they have further plans for the core that make such draconian measures necessary in the future...and they don't want even a backdoor method of other scripts being included in the Warehouse.
I'm assuming that if you were building a script from the ground up, it would not make a huge difference to build it EW-compliant.Basically, they are not giving legacy plugins from the fan base here too much thought...because whether it's a plugin or some other modus operandus, we've been developing workarounds for years...like the SCF script...so they know we'll cope whatever the policy.
It seems a bit mean on people like Fredo who have hugely contributed to making SU what it is today; but I'm pretty sure that any wider SU userbase will get to hear about the present scripts one way or another, even if the SCF plugin itself has been denied access to the EW.If it's not some situation like this, they've probably just shot themselves in the foot for no particular reason.
-
@tig said:
The EW rules pretty much pertain to them having the ability to 'uninstall' their EW extensions: because their tool will remove the loader rb [gettable in v2013 from the extension's methods] and any subfolder with it of the same name !
Ooops!
Then I might have a problem here because the top rb file is actually not the declared loader of the extension. The true extension loader is in the folder (called _loader.rb) for all my scripts.Another headache in perspective
Fredo
-
-
I also find the SCF Plugin Store Extension Manager and Plugin Managers very convenient and nicely designed for this purpose (big windows, clear In / out state, etc...);
EWH does only manage extensions and the very small window in the Preferences Panel may become difficult manage with hundreds of plugin extensions.
So that's another reason to use the Plugin Store, even if we also use EWH.
Fredo
-
Perhaps they are planning to release a Pro only utility similar to the excellent plugin store, and are attempting to limit the number of people who know about it. I'm sure there are many many SU users who have no idea of plugin and will see the EW as a thing. I've had a look at it but find it cumbersome and have yet to find a reason to use it.
-
@rich o brien said:
We did submit and it was refused.
Looks like they wont bother to answer on a direct question at:
http://www.blogger.com/comment.g?blogID=5684885087366507074&postID=7249709507814990061&isPopup=falsePersonally I have not yet find any particular good reason to use extension warehouse, but I certainly do understand it's importance to plugin authors.
-
Gee, I didn't realise I had opened a can of worms....
Thanks guys for clearing that up. I have been a little slow on the uptake of the SCF plugin store so now there's no better time I guess.
-
IMHO you are missing one very important point.
In the last Basecamp JB gave some insight to their long term plan for plugins in SU. What you are seeing is the first small step in the implementation of that plan.
What I read in his words was they were planning to gain control of the “technical integrity” of plugins because it was costing them too much support cost the way things were going. You cannot assume that users will be able to load plugins from the SCF very far into the future. PlugIns will not be part of the native SU ( again cost issue) ,but some what like MS puts their stamp of approval on device drivers etc. Trimbel will want some assurance plugins they allow loaded do not cause SU problems.
How that is done in the end will be interesting to see develop.
Backup FYI For example: data from Microsoft Crash Site) OCA => Online Crash Analysis:
70% caused by third party codes => dll etc;
15% unknown ( memory to corrupt);
10% hardware issues;
5% by MS code -
I'm pretty sure that mac1 is right on the money. What you are seeing here is the shape of things to come. The SCF plugin manager is more user-friendly and a tremendous asset to those of us in this community. If anything nasty slips through the net, there are plenty of experts on hand to help sort out any problems...but you only benefit from that if you are actually part of the community. I've said it before and I'll say it again...users here are not the average user.
Just look at Fredo's JPP plugin. It's been downloaded 34,000 times. Most of us would regard it as an absolutely basic necessity. Yet, if the figure of 30 million SU users is true, then it's only being used by 0.1% of the total userbase...probably fewer than that, if you consider that many will have downloaded it more than once...for different machines etc.
What you are seeing here is the beginning of an Authorized and Unauthorized 'use at your own risk' environment. Trimble, as mac1 suggests, is taking control. The draconian QA requirements in the EW is a maverick filter; Fredo is just 'collateral damage'. That's not to say that he and the other top coders are being taken for granted or ignored. Whether people are happy with the idea or not, the fact remains that SCF is an excellent shop window for talent. I would not be in the least surprised if Chris is the only 'acquisition'. We may not be talking about full-time jobs, but we could well be talking of attractive commissions.
-
Speaking as a plugin developer with 50+ plugins I can wholeheartedly agree that adjusting my old plugins to match the EW requirement for filename and SketchupExtension is a pain. I've still not gotten around to do them all.
But even so, I do think it's a good thing to have some basic quality requirement. How much time haven't we spent on debugging problems that was caused by another plugin modifying the core classes and methods? I've personally wasted all too many hours that I'd care to think of.
With the EW and their statement at Basecamp it's clear they are focusing on SketchUp as a platform. And for that to scale up it makes sense to have some more structure. So despite the pains for existing plugins I think it's a good move when you look at it in the large picture. And we always have the option to install it the old fashioned way - which isn't really needed since the PluginStore takes care of managing all the legacy plugins.
-
thomthom,
I do agree with all you say.
-
The technical requirements of EWH are constraining. Actually, one problem script writers need to take care of is the retro-compatibility, because not everyone has migrated to SU13 and plugins must be installable in other ways, on SU6, SU7, SU8. In addition, managing the transition, with change of names and compliance to EWH installation model leads to a massive update of documentation, posts.
-
We certainly need strict rules to ensure quality of script and ensure a reasonable support collectively. EWH rules are definitely going in the right direction (even if there are some details missing about the update cycle management of scripts).
The only point which could be puzzling would be that Trimble does prehempt script distribution. I don't think this is the case, but as they are the official owner of Sketchup, they may think that their liability is more exposed and go for some sort of certification and filtering (like on the App Stores for mobile apps).
Fredo
-
-
- Yes distribution for backward compatibility is an issue. For Vertex Tools, in its website I made the download available in two formats. The recommended is the RBZ - which works in SU8M2+. But as an alternative there is the ZIP format - where I also link to instructions on how to install this package. Under the hood there is only one file - a ZIP file. The name of the file downloaded is prepared in the HTTP headers on a per request basis. So I only have to upload one file. I would have liked to see something similar in both EW and PS.
My wish is that there are clearer guidelines for development and best practices. One thing is the requirements of the EW, but I think that SketchUp's website and API documentation should accommodate developers more with clear and useful guidelines.
Furthermore, I hope that these repositories will in time be able to handle dependencies transparent to the user. So if a package rely on another package it will automatically be installed/updated.
I also wish for GitHub/BitBucket integration - so we can push builds directly from our version control software - automated.
-
@thomthom said:
Furthermore, I hope that these repositories will in time be able to handle dependencies transparent to the user. So if a package rely on another package it will automatically be installed/updated.
I thought EWH had a solution and was about to ask you, because when I installed Guide Tools from EWH, I was prompted for installing tt_lib2 (telling me the file 'core' was missing.
But, looking at your code, it seems to managed from your script and your web site. Well done!
Fredo
Advertisement