specklesystems / speckle-sharp Goto Github PK
View Code? Open in Web Editor NEW.NET SDK, Schema and Connectors: Revit, Rhino, Grasshopper, Dynamo, ETABS, AutoCAD, Civil3D & more.
Home Page: https://speckle.systems
License: Apache License 2.0
.NET SDK, Schema and Connectors: Revit, Rhino, Grasshopper, Dynamo, ETABS, AutoCAD, Civil3D & more.
Home Page: https://speckle.systems
License: Apache License 2.0
If not account has been set up or no default account has been selected (eg it was created then deleted), we should alert the user via an error message and by disabling the nodes that require an account to work.
Add Transport nodes to the Dynamo connector to reflect the Gh ones.
They're present in all converters already. See the revit example.
Will rename them to ConvertToSpeckle( List<object> objects)
rather than have a separate method.
We need another node that can receive objects from transports rather than streams/commits/etc. This one should be less fancy, no auto updates, etc; should just take in a transport and an object id (hash).
Copied over from specklesystems/ConnectorGrasshopper#15
A nitpick: the server transport reports its upload progress per object. This is not bad per se, nevertheless it can be misleading UX wise: a user can be maxing out the upload speed on their connection (which we take care to do this time round), and the progress can still seem slow.
We need to manage expectations better here!
Find a clean way of reporting also bytes sent and eventually bubble up a Mb/s
statistic. Ironically, git does this :D
All clients.
Simple nurbs surfaces should be (may not be!) easy to add.
Following discussions we had in the past, (I think) it was agreed to move the kit selection to an application wide menu so the end users could select a default kit for Gh in general and not on a node basis.
We could even consider a systems-wide implementation and have the default kit selection be in Manager & Core.
Copied over from specklesystems/ConnectorGrasshopper#36
There's quite a few base class methods which are not named correctly, and generally confusing. We need to clean them up and normalise them a wee bit:
GetDynamicMemberNames
-> required by deserialisation, can't change. returns all prop names. To investigate if we can't get rid of or rename this method to something less confusing.GetDynamicPropertyNames
GetTypedProperties
Not sure we need:
HasMember
and HasMember<T>
GetInstanceMemberNames
-> can be replaced with GetTypedProperties
When deserializing a List of integers, we get errors re conversion from Int64 to Int32. We need to fiddle inside the HandleValue function and potentially pass in the innerType of the List/Dictionary for raw values.
This seems to happen currently for List but I suspect Dictionary<string, int> will be affected as well.
There are some problems with the filtering objects UI and it should be re-thought
An option would be to separate them into visual sections: "quick filters" for the ez buttons and "advanced / all filters" for the rest. It would be easier to have "all" vs "advanced" so the filters list wouldn't have to be filtered (lol) to exclude the selection filter.
Alternatively, the two (quick vs all filters) could be in two separate tabs? Would require reconsideration of the backing view model.
Some sketches to be made in figma before this restructuring is executed.
See dynamo implementation from @teocomi. Will need a RequestCancellation() public method on the GHAsyncComponent base.
Copied over from specklesystems/ConnectorGrasshopper#25.
Brief intro to the problem:
The Expand Speckle Object is not picking up instance fields because it's only looking for dynamic members: https://github.com/specklesystems/speckle-sharp/blob/master/ConnectorGrasshopper/ConnectorGrasshopper/Objects/ExpandSpeckleObject.cs#L79
This is an issue with BuiltElement schema classes (img at the bottom). A similar issue appeared in Dynamo when receiveing an unknown object and its properties are expanded in a dictionary.
Proposed solution:
I'd suggest introducing an [SchemaVisibility(Enum.Visibility)]
attribute with a couple of values eg:
This attribute would replace the [SchemaBuilderIgnore]
attribute I just created. And to add it to various sensitive fields eg speckle_type
, id
etc...
Then we can repalace the GetDynamicMembers
and GetInstanceMembers
methods with a GetMembers(Enum.Visibility)
, so that we have more flexibility when requesting the members of an object (by default visibility would be visible
).
Thoughts?
We currently don't support ellipitical arcs, and they are used in Revit.
OK so I've been thinking that some naming in Core is a bit confusing, maybe it's just me, maybe it's some of the git lingo we're using; but let me put down my thoughts and we can discuss next week. I might have also overlooked some other aspects, anyways here we go:
ITransport
to IRemote
. I find it confusing that we have both transports and remotes and that Remote
is a type of transport and that we also have a class named Remote
MemoryTransport
> InMemoryRemote
, SqlLiteObjectTransport
> SqlLiteRemote
, RemoteTransport
> SpeckleRemote
Remote.cs
to SpeckleServer.cs
, because that's what it isSpeckleServer
prop to the SpeckleRemote
instead of passing it as an extra argument to the Upload / Download methodsUpload
to Send
and Download
to Receive
(sorry did't think about this before)Send&Receive
to the IRemote
interface, but this might not be possible since we wanted to allow sending to multiple remotes etc...I'm sure I have overlooked a few aspects but I'm happy to give it a try if we decide to go ahead.
When sending everything in the standard structural sample model, everything sends to the server fine for the initial commit. However, there is a single ModelCurve
that loses its applicationId
which causes SendStream
to fail when trying to update the stream.
Skipping the element for now, but needa figure out how it's escaping ๐ต๏ธโโ๏ธ
We'll need a way to display the ui inside a host wpf element. Currently we can't as it's structured inside one main Window
. This can be abstracted to a UserControl(?).
NOTE: this is not urgent, can be relegated to jan 2021 release.
Move StreamWrapper
class to Core and change ToString overload to use ?u=
instead of @
.
Integration tests should run, and fail or pass normally. What happens one in three times is that they hang for ever and CircleCI times them out at one point.
See Core's pipeline. If manually run again, they pass. The log is not very informative:
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Too long with no output (exceeded 10m0s): context deadline exceeded
I see the IGeometry interface is scaffolded, but not filled in yet :) The main purpose of that is to enforce a few shared properties across all objects that are "spatial" in one way or another:
units
- we need to be able to, at the conversion stage, match element units. These need to be populated from the base document during to speckle conversion; conversely matched against it (or ignored) on to native conversion.
length
- for linear elements (lines, curves, etc.)
area
- for surfaces, meshes, breps, and closed planar curves (TBD if the last is feasible) etc.
volume
- for closed surfaces, meshes, and breps
Other props for online viewer optimisation:
These last ones will be necessary for view angle optimisations, loading order, etc. and should be implemented in a way they can easily be queried from the db.
The CancellationToken is not handled correctly during serialization and it throws a "Cannot resolve reference. The provided transport could not find it." error.
WallTests.WallToNative
failing bc it can't create a wall
The referenced object is not valid, possibly because it has been deleted from the database, or its creation was undone.
at Autodesk.Revit.DB.Element.get_Parameter(BuiltInParameter parameterId)
at SpeckleRevitTests.SpeckleConversionTest.AssertEqualParam(Element expected, Element actual, BuiltInParameter param) in C:\Users\izzy lyseggen\Documents\dev\next\ConverterRevit\SpeckleRevitTests\SpeckleConversionTest.cs:line 137
at SpeckleRevitTests.WallTests.AssertWallEqual(Wall sourceElem, Wall destElem) in C:\Users\izzy lyseggen\Documents\dev\next\ConverterRevit\SpeckleRevitTests\WallTests.cs:line 59
at SpeckleRevitTests.SpeckleConversionTest.SpeckleToNative[T](Action`2 assert) in C:\Users\izzy lyseggen\Documents\dev\next\ConverterRevit\SpeckleRevitTests\SpeckleConversionTest.cs:line 67
at SpeckleRevitTests.WallTests.WallToNative() in C:\Users\izzy lyseggen\Documents\dev\next\ConverterRevit\SpeckleRevitTests\WallTests.cs:line 42
OpeningTests.OpeningToNative
failing bc the opening is not going through anything
One or more errors occurred.
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Wait()
at SpeckleRevitTests.SpeckleConversionTest.SpeckleToNative[T](Action`2 assert) in C:\Users\izzy lyseggen\Documents\dev\next\ConverterRevit\SpeckleRevitTests\SpeckleConversionTest.cs:line 56
at SpeckleRevitTests.OpeningTests.OpeningToNative() in C:\Users\izzy lyseggen\Documents\dev\next\ConverterRevit\SpeckleRevitTests\OpeningTests.cs:line 60
All components are implemented but some of them completely screw up the solution process when hitting F5. Specially if you hammer it several times (as impatient people like me do... ๐ ), the UI will get locked up for several seconds.
I think the main culprit for this is my implementation of in the Create Object component. Have to do some tests to be sure.
Copied over from specklesystems/ConnectorGrasshopper#32.
As we've seen multiple times people developing their own Speckle to Mongo integrations, we could do with an official transport!
This would be an ideal task for a contributor wanting to get familiar with the 2.0 .NET SDK.
Here's the SQLlite transport for reference. Make sure to check out the discourse post on transports beforehand too!
Subscriptions don't work currently, as they fail. It's possibly a combination of:
There's an example usage in the console sketches project on the subs
branch.
Add new icons for the various components/nodes
There's some leftover garbage around from 1.0. It had a reason to exist, but not anymore.
Probably minor refactoring will be needed in converters.
At the moment, GraphQL Client Operations all return standard string errors (eg "Could not create stream"). It would be more helpful if the specific GraphQL errors could be passed on in the message so you don't have to dig all the way into core to find out what the actual error is.
Make any bad GraphQL request using Client.GraphqlClientOperations
.
Pass the actual GraphQL errors into the GraphQLException
.
Just dumping in here the latest discussion takeways. @izzylys feel free to edit/add (this will be an incomplete list):
Sidebar and options: sidebar goes away. The only missing option will be the "Dark/Light" mode button, that can go in the current settings view. The "Pin Window" option can go as we'll rely on the ownership of elements, e.g.:
var helper = new System.Windows.Interop.WindowInteropHelper(Bootstrapper.Application.MainWindow);
helper.Owner = RhinoApp.MainWindowHandle();
Top Bar:
Hopefully this makes sense, if not happy to clarify.
Ie, telemetry.
Currently a list is created of all the Revit elements that failed to convert...then it goes poof bc idk what to do with it.
Decide on a strategy for this. Do we write to local logs in addition to sending to our error tracking? Think having local logs printed would be useful for individual debugging.
At a minimum, we'd want a popup in DesktopUI that displays raw text of the errors with maybe a button to export a txt or something.
You can currently set dynamic props key names to whatever you want them to be, including potentially illegal chars. This is problematic, as there are some caveats that will make things difficult.
Ie,
myCommit["test.the.best.dots"] = etc
should throw an error.@
s. e.g., eg: myCommit["@@@@@test.the.best.dots"] = etc
- works fine but it's stupid and can cause confusion (@teocomi spotted this)speckle_type
)Come up with the scenarios that we want to avoid, and implement them as deep as we can in core so we don't need to freak out later!
There are some that we took care of in 1.0 in the CreateSpeckleObject component, so we could start from there. We also need to investigate other limitations coming from postgres' jsonb column operations this time, as I believe that will be what we'll want to test against.
You should of course be allowed to remove objects from a stream in a Desktop connector! This involves:
desktopui
We envision having multiple transports in the future, with this being a potential area of high community contributions. In the current setup - transports being embedded in the core .proj file - we'll end up with a bazillion third party dependencies.
Move transports out of Core into separate projects. This option leads us towards a monorepo-like situation - which is not particularly bad, as it does imply less management overhead.
Each project will then need to produce its own packages, e.g.:
In the current "reference things locally" phase that we're in, this would mean that connectors will need to locally reference the transports they're using (until we create packages later down the line).
Send node has no option to automatically send when receiving new data, this should be added it we want feature parity with Gh. We might decide not to add it if we want to keep the node simpler and prevent risky behaviours.
It's a bit messy at the moment! The StreamGet
query returns too many things, and at the same time not enough things - or some things that are needed are not there yet ๐
Where this started from: currently, to get the latest commit in a stream, regardless of branch, i have to search through all the branches returned by the original StreamGet
, and then dig inside all of their commits. There's a different field in the schema, the stream's commits, that... just returns the latest commits.
I propose we break this down a bit, and add a few extra calls that will be more on point.
It's an open questions for all the connector implementations!
The most obvious solution for interactions like adding a collaborator or an existing stream was a ComboBox, but I've run into some difficulty with making it work. Searching using the ComboBox input works fine, but selecting an option clears the text and makes it appear to the user that nothing was selected. This is because the SelectedItem and the text input Query are both bound to different props and it's causing conflicts. Need to figure out a better way to handle this or come up with a workaround (eg add selections as chips so they are visually displayed to the user?)
The Revit Connector window should be launched automatically if the file has saved streams and/or it was open the last time the file was in use. This would make a very nice UX!
In the Grasshopper connector, I needed to make shallow copies of any Base
object to prevent the object from updating backwards in the node graph.
I'm pretty sure we will be needing this elsewhere, so It might be a good idea to add it to the Base object directly as ShallowCopy()
.
My quick implementation is here:
The Dynamo connector has no interface for swapping kits, one should be added.
In order to unify all the different names and descriptions we are going to have to put together, I suggest we assemble some sort of resource file where we can locate and easily change those strings without affecting the underlying code.
This would also act as a single "source of truth" for any other place we might need it in, and it'd be a nice step that might allow people creating speckle translations. ๐ช๐ธ๐ซ๐ท๐ฎ๐น๐ฉ๐ช๐ง๐ท
Not sure what this "resource file" should look like though (format, etc...), if we add it in Core it could be a .resx
file. Don't know if we can access that from a dependent project though. I'll see what I can come up with.
What's needed (list open to edits!):
streams:
users:
Should not change the base type. If it's a Objects.Circle, it should return an Objects.Circle
Shallow copy an implemented Base type.
Remote transports should handle error states gracefully. Perhaps we need to introduce an onError event?
PS: throwing errors from inside the ConsumeQueue
function does not help, as it can't be caught anywhere.
Currently there's no way to exit form a Send
or Receive
operation before it's done. This is, obviously, no good!
Pass in an CancellationToken
and honour the cancellation requests throughout the codebase. It can be optional to prevent client work disruption.
It might affect existing 2.0 client work being done in Gh, Revit, Dynamo and Rhino. But not dramatically ๐
The receiver should clear its internal data whenever its stream input is disconnected.
Currently, the Write method will persist the previously received info, but I haven't found it affects in any way the functionality of the Receiver node.
Copied over from specklesystems/ConnectorGrasshopper#35
When a file is opened again, a receiver should check if there are any newer commits on the stream that it's listening at (alternatively, the branch).
This needs to happen ONLY if it's a stream (or branch) receiver, and not if it's a commit receiver.
Needs methods in Core/GQL for getting the
StreamCommits
BranchCommits
Copied over from specklesystems/ConnectorGrasshopper#14
The current objects mainly tackle general geometry and some structural elements. We can't forget about MEP!
A tentative list of basic objects to start:
Feel free to add to the list ๐
BREP Roadmap:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.