Should Trimble Buy More Plugins?
-
I would love to see all of the top plugin developers with unlimited time, resources and access to the backside... I cannot begin to imagine what we would have right now.
-
Based on track record, I'd hardly say real creativity is a strength of the current SketchUp dev team... they seem largely content to slightly refine the software with "safe" updates, and instead focus on integrating web based tools. This may be the fallout of years of association with Google -- what we have now is a more web integrated tool, but not in any way a better modeler.
Big ideas with grand vision simply will not come from this team -- but instead of buying plugins, I would think it a better strategy to bring on the original plugin authors to do their thing... which seems to be happening to some degree. However, since the SketchUp team has long since lost its original focus as a developer of modeling tools, I wonder if the new blood would be used in that way anyway.
It could very well be that the only reason to bring on plugin developers is to strengthen the link to 3rd party developers -- thereby letting people who actually have some creativity do the all heavy lifting for any future development.
Here's my issue with this -- adoption of 3rd party tools (versus native tools) by the larger (more casual) user base may be hampered by a few factors.
-
Consistency of UI -- the 3rd party plugins are often not SketchUp user friendly, and require learning new thought/working processes that many users may not embrace. This can be partially attributed to the fact the the overarching UI infrastructure for more advanced operations is simply not in place... and I doubt it ever will be. What I mean is there is a distinct separation of the native tools windows/dialogs/toolbars, and anything made for 3rd party tools...this is prohibitive to the non-power user to learn.
-
Speed -- there is no doubt that native compiled code will always be faster executing than Ruby.
-
Additional costs -- better tools often cost additional money, with Trimble being more aggressive with the pricing of SketchUp there will be less money available to throw at 3rd party plugins. Users will expect more from the native tools because they are paying more... whether Trimble intends to deliver more is doubtful, but the expectation will be there nonetheless.
This is the reason my preferences run towards a more comprehensive solution like form.z -- all those "plugin-type" tools are native and they obey all of the UI logic and flow naturally from one tool to the other. Concepts can be re-used to shorten the users learning curve, and once mastered become building blocks for more advanced techniques/tools. Whereas in SketchUp each developer is an island unto himself -- which is by design, due to how SketchUp is segregated.
Best,
Jason. -
-
@thomthom said:
Here's the crux of why I don't want plugins assimilated into SketchUp - what you find essential is different fro what I find essential is different from what other find essential. If one then try to find one big compromise then you end up with a huge list of functions - menus, toolbars etc. In other words bloat. Just look at behemoths such as AutoCAD and 3DStudio Max - I use them both and they have a huge collection of functions. Yet, I only use a small fraction of them and I feel lost on every update they make where they rearrange the UI in an attempt to make it more manageable.
That's why a p;lugin based system will allow people to pick and choose. I also use very little of Autocad and it's varied functions.
the end to which I seek is simply investing in success so that it can grow at a faster rate. I just imagine developers making plugins that are free and very useful but having to go to work 9 to 5 to pay the rent. When I imagine they could do even more with more time.
Now that there are two highly qualified plugin and extension installers available I guess that point is kind of moot.
-
@jason_maranto said:
Whereas in SketchUp each developer is an island unto himself -- which is by design, due to how SketchUp is segregated.
This is a concern of mine. And I feel it's also in part of no guidance from SketchUp. The API has been presented in a loose "here -play around with it" kind-of way.
That's why I'm glad the EW has some requirements - that they check for rogue code that might break SketchUp or other plugins.
Though that doesn't address the inconsistent UI though.Here - in my ideal world - there would be offered some UI framework and guidelines. Guidelines in the likes of what you get for Windows and OSX - lots of great resources there to know a good UI is designed.
But a guideline is not enough though - as many plugins are developed quickly as a tool to "just get the work done" - therefore made rather quickly with not too much effort into UI and UX. This is where a framework would be of use - a system that would let developers quickly stack up some simple UI with minimum effort. This should aid into some more consistency.@krisidious said:
unlimited time
Ah man - unlimited time has been on the top of my Christmas list for ... ever. Damn those puny 24 hours. Damn that need for sleep.
-
@krisidious said:
the end to which I seek is simply investing in success so that it can grow at a faster rate. I just imagine developers making plugins that are free and very useful but having to go to work 9 to 5 to pay the rent. When I imagine they could do even more with more time.
Now that there are two highly qualified plugin and extension installers available I guess that point is kind of moot.
You touch upon the very core of why I've been wishing an app-like store for plugins/extensions. To make extensions more visible to the end users. I meet a large amount of people who's never heard of the plugins available to SketchUp. More users of plugins should attract more developers as then it might be a sustainable market for developers to make plugin development into a source of income. And I expect that would in turn increase the quality of the extensions as well.
And now we have two repositories! How awesome is that. And one is built into SketchUp itself - which I look upon as free marketing for all SketchUp extension developers.
-
@thomthom said:
Here's the crux of why I don't want plugins assimilated into SketchUp - what you find essential is different fro what I find essential is different from what other find essential. If one then try to find one big compromise then you end up with a huge list of functions - menus, toolbars etc. In other words bloat. Just look at behemoths such as AutoCAD and 3DStudio Max - I use them both and they have a huge collection of functions. Yet, I only use a small fraction of them and I feel lost on every update they make where they rearrange the UI in an attempt to make it more manageable.
It is a much easier thing to selectively remove elements from the software than to add them -- for a very elegant solution to this problem check out this nifty UI item in form.z 7.x:
I'm specifically talking about the custom Favorites palette, which appears at the current cursor location and is invoked via a keyboard shortcut.
Obviously, one needs to know the program very well before this becomes the default way of interfacing with the program -- but the upside is tremendous in terms of maximizing screen real-estate and narrowing focus to tools you actually use.
Best,
Jason. -
@unknownuser said:
which I look upon as free marketing for all SketchUp extension developers.
I really think as a dev you need to find out if this will remain.
There's zero docs on the roadmap except for the fact they will monetize with ecommerce. will they do that for free? Or charge a % for every plugin you sell?
Someone needs to ask now before to move the goalposts again
-
Fair point.
-
@thomthom said:
Also, it's correct the Ruby is slow. Very slow. Scripting languages are in nature slow because they are interpreted in real time. They cannot compete with native C code. Fortunately for Ruby one has the possibility to create Ruby C Extensions where it's possible to leverage C - which I did in Vertex Tools in order to ensure it's performance.
Whilst it may well be true that Ruby is slow, this is most decidedly not true for all languages that you might describe as 'scripting languages'. For example, it's not true that they have to be interpreted in any sense, let alone the very simplistic way implied by 'in real time'. I'm fairly experienced in implementing this stuff (like, 30 years) so forgive me if I pontificate for a few paragraphs; if this sort of thing doesn't interest you feel free to skip it.
One can implement a language as a very naive interpreter, rather like many early BASIC systems, where the actual underlying system reads the code (which might be actual text fragment by fragment and executes each bit in turn. Parsing each line every time is probably the slowest possible way to implement an language, but there may be worse things to do.
Pre-tokenising (i.e. converting the text to a list of simple flags that mean "set variable name to {next thing on stack}" or similar) saves time and simplifies the exception engine a bit.
Going a bit further actually compiles the text into sequences of simple instructions to a virtual machine that then does the real work at run time. You can do some tricks to optimise the code at this level, some of them very effective. If you define your system nicely you can make nice portable debuggers that work the same on any machine that runs the system. A very good example of this approach is Smalltalk, where one can write a program on a Mac, copy the running system across to a PC, continue running it, debug it on RISC OS, deploy it on linux and rely on it working the same everywhere. Ruby is supposed to work very similarly but to be honest I don't find the semantics and syntax anywhere near as easy to use as Smalltalk's.
A next step, that can provide dramatic performance improvements, is to take those compiled pseudo-instructions and decode them at run-time and (this is the different bit) save the decoded native machine instructions for later use. Clearly you have to be clever about how much of it you keep around taking up space, how you handle debugging (since you debug the 'real code' and not the machine code) and quite few other important details. That's why it isn't done for all systems.
Smalltalk was the first system to use this scheme starting back in '84, but it was adopted by java (spit) too when it arrived on the scene. Python is likely to get a similar system sometime and I see no special reason Ruby couldn't. The performance benefits can be dramatic.
One has to remember though that speeding up your Ruby plugins may not make much overall difference to the speed of the total work being done. If your code is driving some complex operation in SU and your code is really taking 1% of the time, then making Ruby a million times faster won't buy you anything useful.
@thomthom said:
Just a pre-emptive answer in case any one should suggest that Trimble buys plugins and convert them to native C; There is no point of buying the Ruby code - it wouldn't give anything for free to developing the C code.
Actually I think it would have a point in some cases; the design of the plugin is not just in the code. It's also in the mind(s) of the developer and includes stuff not yet working, ideas for the future, knowledge about approaches that worked and failed etc. Choosing an important plugin, contracting with the original writer and working with them to re-implement, extend or simply better support it, would be of non-trivial value.
-
Yes, I would.
And it is my belief that is exactly what Trimble intends to do. Let Sketchup remain the un-bloated jewel that it is and offer plugins for the various industries served such as engineering, architectural, construction, game design, etc...
I don't use Sketchup professionally but that is my goal. For many years I worked as a Production Superintendent in Paper Mills. Until discovering Sketchup I created training materials with Visio and Excel to train the production workforce. Effective but not efficient. And certainly not eye candy. Paper Mills have hundreds of pumps, motors, valves, rolls, vessels, instrumentation, and miles of piping twisting in every angle imaginable.
Thanks to the ruby plugin guys here I can create a realistic 3d drawing of a process that knocks the socks off of people in the industry I've shown them to. But it's a slow process. To do it professionally I would need a professional plugin with an extensive library of components and materials. To create such a plugin would be very expensive I would imagine. This is where Trimble comes in.
-
To me it seems SketchUp has been trying to "preserve" much of the goodness and success of @Last, where real innovative features had been added. Incompatibility would have been a risk for this valuable heritage and trust of users (there are other softwares that would become incompatible in much shorter time). But progress and new innovation must still happen.
The EWH with its acceptance criteria (and being included only in SU2013) would have been a chance for a break. Now the break will certainly be in 2014, and EWH will include both compatible and incompatible extensions.
I try already to write for Ruby 2.0, and use rather fallbacks for 1.8.6-specific things. -
@tim said:
Whilst it may well be true that Ruby is slow...
Which leads to another point - OK, so Ruby will never beat compiled 'C', BUT why are we still stuck with Ruby 1.8.x?
I use 1.9.3 on a regular basis, which has a whole new byte-code interpreter (YARV), which truly is much faster - operations can take as little as 25% of the time of 1.8.6.
And far more of the Ruby standard libraries are 'C' coded too, rather than being native Ruby files.
The only objection I can see to upgrading Ruby, is that there are certain syntax changes etc. that would involve developers having to make minor alterations to their code.What better time to do this than at the release of the new 'Extensions Warehouse'? Many developers will have to tweak their code anyway to meet the new guidelines, and a system is in place to, at least in some small way QC the code before admission.
This seems like yet another missed opportunity.
I personally rather like the way that plugin dev's currently are independent, so prefer to see the EW as a way for dev's to monetize their hard work - they would surely lose some ability to be so innovative if they were 'bought out' by a large corporation like Trimble (which has yet to show any sign of real 'innovation').
If the EW is so important to Trimble, what better way to show their commitment than to say to the dev's "hey, we just made all your plugins four times faster, and we'll help you to adapt your code to the changes".
The lack of this makes me suspect that in the long-run, the EW won't be used to benefit independent developers very much at all - rather, it will be used by Trimble to promote their own 'C' extensions, and charge users extra for features that should be incoprporated into the main program.
That might be OK if the building blocks of a "roll your own" system were cheap enough, but the hike in licence costs, for so little benefit, of this release does not bode well for that model.It also raises the possibility that the EW could be to the detriment of small developers - Trimble now have a way to easily track which plugins are most popular. This makes it very easy for them to pull the rug out from under a successful plugin by implementing their own version. I mean no disrespect to the amazing work done by the Ruby dev's here - but the guys who sign my purchase orders at work are much more easily convinced to spend cash on 'official' software than something they might perceive as 'amateur' ("What? PayPal, you must be kidding!")
My own Ruby efforts are meagre compared to the likes of ThomThom, Fredo, TIG etc. - but even if I though they were good enough to monetize in some way, I would stick with our own Plugin Store - because I know that the guys who run this place really do have the best interests of the user base at heart.
-
@aerilius said:
I try already to write for Ruby 2.0, and use rather fallbacks for 1.8.6-specific things.
You where writing a SketchUp shim, right? Are you able to use that to test compatibility? Test if a file will load etc - see if there are syntax error.
-
I haven't written something like that. So far I only take care and add switches for the differences (
String.[],methods["method_name"] || methods[:method_name], …)
Advertisement