Fredo's plugins not in Extension Warehouse...?
-
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
-
Yea - I implemented that system some months ago because I kept getting users who didn't read the requirement of TT_Lib. With the release of EW and SU2013 I tweaked it so it will launch the EW window with the entry for TT_Lib open. Users of older SketchUp versions will get a direct download to my BitBucket repo hosting.
But I still wish it was all done transparently. That way it would be easier to develop framework and packages which developers can easily implement and deploy.
-
@fredo6 said:
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.
SU8 free will probably be a commercial use for long time among those who need SU rarely or if SU2013 is simply too expensive. I also do know some that actually do consider if SU2013 is worth to upgrade from SU8. SU8 works ok and it's functionality is rather easy to extend with existing plugins.
Sounds like PITA if SU2013 compatible plugins cannot be installed directly on SU8, is it really so? -
SU2013 didn't introduce any new API methods AFIK - so I don't see any reason why plugins between SU8 and SU2013 cannot be exchanged.
-
FYI : After downloading Su2013 I re-named its plugin folder, created a new plugin folder and copied all may SU8 plugins to SU 2013.The native download of Su2013 does not include ruby script examples, ocean modeling, cost etc and if you do not have those the plugin menu bar will not show( Think ruby script examples is required)unless you have a script loaded that also enables it. I removed those which were brought over from SU8 just encase , re downloaded and then copied the remaining files from the 2013 folder back to plugin. Things work great so far
Advertisement