Fredo's plugins not in Extension Warehouse...?
-
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