Should Trimble Buy More Plugins?
-
Shouldn't Trimble buy more plugins from the Authors and incorporate them into the software to create a more robust system? Thereby supporting part time developers to do more and more? Time is money and I just cannot imagine the time and effort it takes for all of these plugin developers to create these things. I know they (Trimble) do it sometimes... But think they should do it more. Yes, I know wanted or needed plugins vary between users, however Trimble now has their extension warehouse, so they could make these tools additional and still proprietary. Isn't that the entire business model of Autodesk?
-
Only if the deliver the function/feature advertised
Based on my experience with plugins on this site....profession baseball pitches have better batting averages -
@krisidious said:
Shouldn't Trimble buy more plugins from the Authors and incorporate them into the software to create a more robust system?
what are some examples you're thinking of?
because for the most part, i don't think they should buy any plugins if they were going to go into the native app itself.. they should do the programming themselves.
an example is the solid tools.. they(google) didn't have to (nor do i feel they should of) buy booltools.rb in order to get those functions in the app.
in contrast, i'm under the impression dynamic components started out as a non-employee quest then sketchup acquired the scripts.. (but i don't know this for fact)
-
I have to disagree if the plugin has already been made, because the infringement angle is a bit acute. How many ways are there to skin a cat? a few but they are all technically the same action. Things I would have bought for Trimble if I ran the show? Vertex Tools, Mirror, Curvizard, Edge Tools, Timeclock, Customtoolbars, Curve Shear, Select tools, Section Cutface, SU Hatch... I could go on. All of these seem like Native tools and some of them like Mirror are damn near essential.
I think you're right about the Dynamic Comps and I think Chris told me the other day that Sandbox, North Arrow and Google tools are rubies and not native.
-
@krisidious said:
Vertex Tools, Mirror, Curvizard, Edge Tools, Timeclock, Customtoolbars, Curve Shear, Select tools, Section Cutface, SU Hatch... I could go on.
none of those are original ideas per se.. a lot of other apps have these same functions already.
if trimble were to actually purchase something from a plugin writer, it would be along the lines of an ingenious algorithm which they need to copy in order to provide optimum functionality.but say they bought something like weld.rb and it functions exactly like weld.rb does and it's the same script which is placed in the same plugin folder and available in the plugins menu (etcetc)..
that would be pretty damn cheesy to have it function as it does within the native app.. (for instance, weld.rb has a couple of useless questions which the user must answer prior to exiting the tool where as none of the vanilla tools have this weirdness.. the native app must (or should) maintain a consistency across all or most functions..)fredo has some awesome awesome stuff but his UI wouldn't fly if it were a native tool.. i could see trimble possibly wanting some of his code and maybe paying for that but as far as outright purchasing curviloft.rb and including it in the app, i don't see it happening.. as in- no way would that happen.
further- curviloft and TIG's extrusion tools share some similarities in the results.. but neither of them copied the other because it's not always the same route from point A to B.. in fact, their two approaches are possibly very different from each other even though we, the end user, may see comparable results in circumstances..
likewise, if trimble wanted to add more complex skinning tools, i'll go ahead and guess they wouldn't even look at tig's or fredo's code.. they would approach it with a fresh state of mind- especially because they have access to sketchup's core functionality whereas the ruby writers have to take a different and more limited approach.
but maybe, just maybe they would hit a brick wall because they couldn't figure out how to arrive at point B properly in which case they would possibly contact or contract one of the ruby writers for help ($).. but that scenario does seem a bit far fetched to me.
in reality, if trimble wanted to incorporate the ruby writers into the monetary aspects of the app, i believe they would model the setup to be something more like apple's app store (and we've already seen the beginning of this.. basically, trimble provides the platform and audience for the ruby writers to sell their stuff while they themselves get a percentage of sales..)
@unknownuser said:
I think you're right about the Dynamic Comps and I think Chris told me the other day that Sandbox, North Arrow and Google tools are rubies and not native.
well yeah.. you can see them in your plugins folders as .rb files.. what i was saying though was that i think DCs were written by someone not affiliated with google.
[EDIT] i guess the gist of what i'm saying though is this-- if the future of sketchup was to head in the direction of "oh, hey.. we don't have to do any programming.. we'll just sit around and buy other people's rubies then place them in the app.. genius!! " then there's definitely no future at all in the app.
I already feel* they (the suTeam) are listening too much to comments such as "It's the ruby writers that are keeping this thing alive!!" (or whatever) while ignoring the fact that many new functions can and should be added to the app itself.. without bloating it.. i mean, it's already bloated in some ways depending on how one may look at it..*and it's not even that i feel this way.. i have seen (and can link to), comments by suTeam members which say "well, this could be accomplished with ruby"..
-
really good points...
I was under the impression that ruby was pretty much the same as the backside of sketchup just unavailable for certain commands, but I don't know anything about it. I thought those rubies I mentioned were rubies because they got them from someone else.
as for the other software doing the same thing I don't think there is anything proprietary about drawing a line or designing a tool that does vertex editing as a whole or any of the things that almost all of the systems utilize. The idea has happened, my real concern about the infringement is doing it almost the same way.
Like I said, you make a lot of good points about why they're not doing it now...
-
I agree with Jeff, how would it add a selling point if SketchUp came with included tools that a) work the same way as in other software and b) are already available in the Extension Warehouse? Maybe even not everyone would find them useful. They have just begun removing rarely used functionality and making them optional add-ons.
@unknownuser said:
…they would approach it with a fresh state of mind…
That's what many expected to see in recent releases, but the last time that happened was @ last. The innovative tools that have a vision and inspiration are all those that have been in SketchUp for many years (pushpull, followme, etc.). Later solid tools where added, not world-shaking new, but that was mainly worth the investment because boolean operations are faster in native code.
Now something new! -
@unknownuser said:
but that was mainly worth the investment because boolean operations are faster in native code.
And seems that is exactly the same for any Ruby script made strictly with Ruby language ?
-
It's a clear no from me. I don't see any advantage of that - only disadvantages.
Just consider the update flexibility by having these plugins made by third party developer. Now, if they where bought - who would maitain them? The SketchUp team - consuming even more resources? The original authors - meaning they'd have to be hired? It immediately makes the development and release cycles of these tools more rigid.
@krisidious said:
Things I would have bought for Trimble if I ran the show? Vertex Tools, Mirror, Curvizard, Edge Tools, Timeclock, Customtoolbars, Curve Shear, Select tools, Section Cutface, SU Hatch... I could go on. All of these seem like Native tools and some of them like Mirror are damn near essential.
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.
As we saw with 2013, they moved several of the ruby extensions that used to ship with SU into the warehouse - making them optional. Which I think it's a good move. Keep the core simple - let people build their own SketchUp.
If Trimble bought lots of plugins and put them in the Warehouse - what would be the advantage? I cannot see none.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.
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.
So in summary - I think SketchUp benefit from remaining simple and lean. Let people customize SketchUp to suite their needs. Give plugin developers more power via the Ruby API to develop more great plugins. UI is an issue though, I agree - because webdialogs are troubles with platform differences and complicates UI development. Drawing on screen (viewport) and one has to make your own framework because one only has methods to draw geometric shapes. Here I miss an open source framework for which people can utilize.
-
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:
http://www.formz.com/manuals/formz7/!SSL!/WebHelp/03083_Tool_Manager_and_Favorites.html
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.
Advertisement