Well, the first and foremost thing would be the lack of documentation.
Now, don’t get me wrong. The samples on github, the bits of information on the guides page are fantastic. And the forums are full of helpful topics and the effort that @dale, @nathanletwory and other team members from Rhino put into answering any queries on the forums is awesome. They have my full respect.
But, a proper and helpful API documentation and a introductory “fundamental” readings are greatly lacking, specially for the C++ developers. I’ve been through Rhino Phython and Rhinocommon docs and guides, and they are way better than the c++ section.
So, in short, not having a comprehensive documentation and API is my biggest development barrier. Everything else is great
One of the main problems we have over and over again is the usage of (linked)blocks, importing and exporting geometry, linking it etc.
While scripting the import/export command does work, it’s not ideal, as you have to add geometry to the doc, select it and then export it, instead of just writing it directly to a file. This might seem like a minor issue, but if you have 1-10000 blocks per doc, it seriouslydecreased usability and probably performance, too.
Also, some inconsistency(?)-issues within RhinoCommon sometimes makes it hard to find what you need - or, impossible to do it the same way as you did before.
Rhino.FileIO.File3dm file = new Rhino.FileIO.File3dm();
Rhino.FileIO.File3dmWriteOptions options = new Rhino.FileIO.File3dmWriteOptions();
file.Write(path, options);
I’m glad that the people at McNeel created this topic.
Thank you very much for your openness.
In my opinion, Eto is the most difficult part.
I think Eto is a minor library.
Because it is a minor library, it is lacking in features, documentation, and samples.
I also think that modern GUI development best practices such as the Flux architecture are not available in Eto.
It would be great if you would consider adopting a major and modern library like ReactNative in the future.