Atributes size
-
Your welcome!
-
Since the user decided to deactivate that extensions I would recommend not relying on the methods it implements. You're loading parts of an extension that the user didn't want to load.
That said, the DC adds to the SketchUp API classes - personally I would like to see them part of the official API. As they are now they are unsupported.
-
@tt_su said:
Since the user decided to deactivate that extensions I would recommend not relying on the methods it implements. You're loading parts of an extension that the user didn't want to load.
That said, the DC adds to the SketchUp API classes - personally I would like to see them part of the official API. As they are now they are unsupported.
I do not think that it so.
The user can know nothing about DC.
But it uses these SketchUp API classes when includes "Generate Report" -
@tt_su said:
Since the user decided to deactivate that extensions I would recommend not relying on the methods it implements. You're loading parts of an extension that the user didn't want to load.
I did not say that. I said IF the user turned off the DC extension, then we have to load "dcutils.rbs" to make the API additions.
@tt_su said:
That said, the DC adds to the SketchUp API classes - personally I would like to see them part of the official API.
AGREED. And they need to be documented!
@tt_su said:
As they are now they are unsupported.
I am not sure I would agree with this statement. The DC package is being maintained, isn't it?
Hmmm.. thinking on that... it seems the minimum changes needed have been done to keep DCs working, but the performance has been going downhill.Regardless of the talking points,... these additions all make sense and should be supported !
Forcing the load of these additions should not matter as most people run the DC extension anyway.
-
@dan rathbun said:
I am not sure I would agree with this statement. The DC package is being maintained, isn't it?
They are unsupported in terms of the API. They where implemented for use in DC. While we support DC, there is no guaranty the methods DC implement won't change.
-
So what do YOU want US to do, Thomas !?
Should WE just steal the code and load it from OUR code set ?
Geez.. TT you have been sucked IN to the blackhole !
Give us some constructive advice.. please!
Not this wishywashy .. your in limboland now BS!
-
He's been trimbled! Maybe more of us need to join SketchUp to "sketchucationize" Trimble?
By embedding that small snippet in our code, we avoid indeed dependencies that could be broken. But on the other side our copied code doesn't get bugfixed when the shared library or API gets bugfixes.
-
Exactly why I preferred to require the original Trimble file from the Trimble folder.
Those extensions have been around for like 4 major SketchUp versions.
Bake them into the API already dag-nabbit!
Stand behind them. They make sense, and are needed.
If they weren't they wouldn't have been written. -
I fully agree that they would be great additions to the API.
But I just wanted to point out that utilizing undocumented features risk being broken. Which is why I on principle don't recommend that. (Note, that's just my recommendation, it's not the law or anything.)
Say if we did implement them into our public API, then they would no longer be part of the DC package - and extensions that require that particular file might break if we had no longer use for that file. DC source might change in structure and organization, file names might change. Just look a the conditional require in the original post - it's not a robust solution.
There is also scripts that hook into the observers and internal variables of DC, which is also prone to break when changes to DC are made. That's something one has to be aware of when utilizing internal methods.
I'm going to make sure there is an feature request for implementing the methods that DC extend as part of the full API. I think there is, but I'll make sure to bump it.
I encourage developer to make feature requests that would improve our API. For the first time in SketchUp we have a dedicated team for maintaining it. We are going over years of old issues and re-prioritizing them. The biggest challenge is picking what to do first - and your input helps here. -
Oh getting picky... OK.
What I'd likely do is test for functionality first to see if the method wanted had been added to the class in question.
If not, then test for existence of the file name.
If that didn't work... bail out and tell the user somehow.
-
@dan rathbun said:
Oh getting picky... OK.
What I'd likely do is test for functionality first to see if the method wanted had been added to the class in question.
If not, then test for existence of the file name.
If that didn't work... bail out and tell the user somehow.
Yes, there are certainly ways to handle it and indeed make it more robust. Which is what one really want to do when making use of undocumented features: account for possible failure.
Now, of the methods that DC implements, the Transformation methods appear the most popular. However, in the source code of some of these, xscale, yscale and zscale - there is a TODO written up to make them return negative values. That would be useful to detect flipped transformation. As they are now they don't do that. And here lies another problem with using undocumented features. If where where to make the DC methods part of the API as-is then we'd inherit this limitation which isn't ideal. The methods was added with this limitation because DC didn't need that. But as an API method it really should offer more generic use.
There are also methods added to UI::WebDialog and Sketchup::Drawingelement which to me looks like there they are workarounds. Without having dug too deep it seems to me that there are methods in our C++ core we could expose that would make them more useful and simpler. Anther reason why one may not want to rubber-stamp these methods into the API.
It'd be unfortunate to inherit even more awkward API methods. We'd rather like to clean up the API.
Oh, just noticed another comment regarding rotx, roty and rotz:
# TODO; There are some specific states where these don't seem # to return correct values. It's probably some range errors in the trig # functions, but I'm not sure yet. One example is placing a glue to # component on the right side of a building and then scaling it...This is another indication that they are not prime for public API until they have been reviewed and improved. And fixing them might mean their behaviour could change in some cases.
That's the background behind my caveat utilitor warning on relying on these methods as they are currently implemented. They where "good enough" for DC, but maybe not be good enough for public API.
-
If they are not good enough for the API, then they would have better never been added to the API by a script.
The concern that these undocumented methods are already widely used, seems to make SketchUp hesitate to make changes (or fix them and add them officially). But at the same time we don't want third-party scripts to modify the API. Wouldn't it make sense to โ at least โ wrap these methods properly into the DC module, so that it is clear they are not for common use? Deprecate them! Maybe keep aliases that puts "Method rotx is undocumented and deprecated. Don't use it.", but get rid of them from the API namespace.
Waiting will only make them more widely used.
-
@aerilius said:
If they are not good enough for the API, then they would have better never been added to the API by a script.
To be picky here, they where not added to the API, the DC extension added methods to the classes of the API. Even though they are defined by an extension made by SketchUp it doesn't make them part of the API.
@aerilius said:
The concern that these undocumented methods are already widely used, seems to make SketchUp hesitate to make changes (or fix them and add them officially). But at the same time we don't want third-party scripts to modify the API.
It's not just DC that modifies the API methods and classes, but also Sandbox Tools. Keep in mind that these extensions where created a long time ago before best practices where established. Leaving us today with the need to clean this up.
Personally I'm of the opinion that if it's useful for us it's useful for third party developers.@aerilius said:
Wouldn't it make sense to โ at least โ wrap these methods properly into the DC module, so that it is clear they are not for common use? Deprecate them! Maybe keep aliases that puts "Method rotx is undocumented and deprecated. Don't use it.", but get rid of them from the API namespace.
Fully agree! Our extensions should ideally follow the same guidelines we provide. Only reason it's not been done yet is that it's just one of a thousand things we got on our list to do. Re-factoring the extensions would mean touching pretty much all the code, which in turns means quality checking for regressions etc and ensuring backward compatibility with older SketchUp versions. It's not as trivial as it might initially appear. All that needs to be weighed in with all the other things we have on our list.
@aerilius said:
so that it is clear they are not for common use?
It should be clear already though. Anything that isn't documented in our API docs isn't meant for public consumption. That's something that applies to any API, not just ours.
There are other methods as well that SketchUp defines, but they are also not documented because they are there for our QA testing.
We also have the task of going though the script examples that has been provided through-up the years. There are bad examples amongst these as well. As this matter of DC demonstrates, it eventually backfires at it set bad precedence.
-
Respected Den!
I feel that became the originator of attacks to you.
I did not want that it was so.
I make to you the apologies... -
It is OK, goga.
We love a good debate!
Advertisement