Should Trimble write plugins?
-
They can't upgrade for ever
maybe toolpacks is a better way for them. -
Thanks Tig and Jeff, Yes this all makes sense.
I guess my question comes, as I have heard John Bacus state both at BaseCamp and in the forums, in particular in reference to 32 versus 64 bit discussions, that a major rewrite of the core would be necessary to accomplish this.
So could is it a case where, when you start changing certain functions within the core coding, it has implications serious and otherwise) both within the core code, and API scripts? -
If it's a properly designed API, it shouldn't happen (but could). That's also the advantage of an API, a "programming interface", that it's a stable set of commands to connect to the core (no matter what algorithms work in the core or whether the core is rewritten etc.). All SketchUp features would ideally be written by using its API, where as processing-heavy algorithms (intersections, ray casting) would be added as API methods.
I think we can distinguish here two questions:
• Whether Trimble-provided tools should also use the API (and be equal to plugins).
• Whether the API and tools should be based on a scripting language or a compiled (binary) language (C++). Actually that soon won't make much speed difference anymore, since modern scripting languages are executed as super-fast binary code (produced by just-in-time compilers). -
Individual 'staffers' have written plugins and I hope that continues.
I think 'Trimble' should at least 'vet' scrambled rbs both free and commercial.
When we add 'plugins' it's to enhance their product in our workflow, having supplied both the API and the scrambler, I think they have a 'duty of care' to the end user to at least check the safety/security of those plugins.john
-
I see no conflict with Trimble writing plugins. If you take the basic ui as a start and then add 'packs' of plugins that would tailor the program to different uses (architecture for example), there could be a defferent sketchup for users in different professions. Always acknowledging that there will be writiers of scripts from within the user community. It might even be a method of increasing the sales of pro and be something that could (note use of the word COULD) be used to keep the cost of pro down, another method of increasing sales.
I would be a fan of this type of system as long as the age old issues of the core could be addressed. A more stable sketchup with hopefully 64 bit support and more control of the standard of plugins would be very welcome so perhaps a more stable system plus support for independent script writers would be a decent balance.
I agree that a ui full of wasteful icons would be a detrimental step so possibly this idea would make others happy too?
-
What is this Obsession SketchUp users have with 64bit?
Its not going to "make it more stable" or "make it faster".
I don't know who fed you guys this idea, but they should be slapped. And told to stand in the corner.There are some areas of SketchUp internals that (I suspect) could do with some refactoring and would likely result in less memory use and therefore better performance and stability, and with a code base this old, I can well understand the concerns "Team SketchUp" may have with the 'nuke and re-pave' option.
-
64bit should rather be seen as "another possibility" for those programs who need it. It does not mean that every program has to become sooner or later a 64bit version, without technical reasons or advantages. In fact, some/many programs are purposely released as 32bit version where it is faster or lighter on memory.
-
@adamb said:
What is this Obsession SketchUp users have with 64bit?
Its not going to "make it more stable" or "make it faster".
I don't know who fed you guys this idea, but they should be slapped. And told to stand in the corner.not sure but i pretty much guarantee if/when sketchup goes 64bit, they (trimble) will sure as shlt be touting "now 64 bit!!!!"
-
If you use larger or more sophisticated models you will need 64 bit support and it will not go away because some folk get personal when others mention it. If you want 32 bit fine, I happen to want 64 bit support. Now if you want to go and stand in the corner it is your prerogative. Personally I go for the right to chose. Clear enough kiddies?
-
@mike amos said:
If you use larger or more sophisticated models you will need 64 bit support
Really, you won't. Memory isn't the bottleneck that needs widening to make larger and more sophisticated models.
john
. -
@jbacus said:
Really, you won't. Memory isn't the bottleneck that needs widening to make larger and more sophisticated models.
We wouldn't run out of memory when rendering with Vray...
-
re: 32bit versus 64 -- So how come moderately large files take ages to open in Sketchup, versus in other software I use that is 64bit, super large files open very fast.
re: plugins -- I do hope that sketchup devs and other Trimble teams will write plugins, otherwise, I could imagine that this ecosystem would start to get less attention and resources, if it's not being used by the makers and owners of SU.
-
@unknownuser said:
So how come moderately large files take ages to open in Sketchup[...]
Something takes long (=time, not memory), apparently there is a lot of CPU processing involved.
Compare for example exporting a big model to stl vs. importing from stl. It seems SketchUp takes more time to initialize its internal model data structures, which can't be compared to other softwares. -
@aerilius said:
@unknownuser said:
So how come moderately large files take ages to open in Sketchup[...]
Something takes long (=time, not memory), apparently there is a lot of CPU processing involved.
Compare for example exporting a big model to stl vs. importing from stl. It seems SketchUp takes more time to initialize its internal model data structures, which can't be compared to other softwares.Interesting. So you think SU would take a long time to "think" about a model regardless of the bit depth of its files? Well, seeing how bogged down SU can get with loads of plugins, I guess it makes sense that the content of a model file can bog down SU as well. It just seems that there are an awful lot of events in SU that just "take the long way 'round". Oh well, so SU is fast and nimble ...until it's not.
Which I suppose argues against Trimble adding yet more plugins to an already sluggish program (at higher poly-counts of course - which is what terrain data is for example...) -
What I got out of the base camp video is they will shortly institute some type of rules / control on plugins because they were spending too much times on working problems they ( plugins ) were causing. Expect this as one of the first changes since it must have been an issue before Trimble
-
@mac1 said:
What I got out of the base camp video is they will shortly institute some type of rules / control on plugins because they were spending too much times on working problems they ( plugins ) were causing. Expect this as one of the first changes since it must have been an issue before Trimble
yeah.. something like that sounds cool..
i also think it be nice if they gave a set of (suggested) guidelines for plugins which will be available to the public.."we recommend using modeless operations unless there's no other options (then make sure the user knows when they're back in sketchup)… try to keep popups to a minimum.. users don't want to answer a bunch of yes/no questions upon leaving the tool.. one step undoable.. etc.."
and maybe offer more in the way of UI help to the writers.. make it easier for them to obtain consistent UI between SU, their plugins, and other writer's plugins..
especially for the lesser used plugins.. if you don't use them super often then you'll often forget exactly how to use them when you need them.. which can more often than not be attributed to foreign UI elements/conventions..then, for good measure, put a couple of their own out every year as examples to these guidelines.. or, as a sort of testing ground for ideas that may/may not be brought into the core app itself..
-
re:64 bit
if making sketchup 64 bit will allow sketchup to have real thumbnails with those big beautiful quick look previews then that alone makes me 100% back it..
a whole lot of work for a little bit of joy.. so what
-
I haven't yet gotten the connection between thumbnails and 64bit.
But... Why not just compile SketchUp to 64bit, no matter how disadvantageous and slow it could be, nobody would complain anymore, and SketchUcation discussions would be shorter.
As for UI, ... ... ... and ... ..., ... and ... and there is already the instructor and the LangHander that plugin developers have access to – although it's useless since the
%(#000000)[rbz]installer can't install instructor content or language files (into the Resources folder). I wonder how they want to pull out of the loop without introducing a new extension format%(#000000)[rbz2]. -
Sorry, didn't mean to re-ignite the 32, 64bit debate with my comment.
I was just trying to understand the difference between what's under the hood in the core, and what I put into the gas tank in the form of plugins.
It's hard for me to answer Jeff's original question, "Should Trimble Write Plugins" without understanding the relationship between these two better. -
@dale said:
Sorry, didn't mean to re-ignite the 32, 64bit debate with my comment
See this thread or any of the many others on the same topic.
@dale said:
I was just trying to understand the difference between what's under the hood in the core, and what I put into the gas tank in the form of plugins.
SketchUp's Ruby API exposes a broad range of SketchUp internals and it permits 3rd-party developers to build profoundly powerful extensions to SketchUp's core tool set. With power must come responsibility— it is entirely possible to write extensions which cause crashes and other sorts of general instability in the core SketchUp application.
While most Ruby developers are quite good about testing their code inside SketchUp, the interactions between extensions are almost impossible for anyone to test. Many of you reading this thread probably have dozens of Rubies installed at the same time. There really isn't a good way to ensure that these will all work well together.
You could argue that we should make it impossible for poorly coded Ruby scripts to crash SketchUp. In fact, we do two things in this area. First, we track down developers who have written code that causes crashes that we see in our crash reports— and we help them fix their code. Second, we modify Ruby methods inside SketchUp such that they are harder to crash. The reality is, however, that poorly coded Ruby scripts will always be able to crash SketchUp.
As you heard me say at 3D Basecamp this year (about 35 min in) we are working to bring some order to the chaos of Ruby development. The Ruby API has been a great success from my perspective. I have even studied it academically. I think you'd probably all agree, however, that a little bit more structure wouldn't hurt. You've seen us already launching things that will help.
There's a fine line between the work the SketchUp team does for Ruby developers and the work that those developers do for their user communities. Users love to have new features— but you can't have features without a solid platform underneath. We're all in this together.
john
.
Advertisement