Eto gridView binding to observableCollection (including a Rhino-crasher piece of sh.. code)

For Rhino yes. But Eto also wraps WinForms and Gtk.

– Dale

1 Like

Does it mean that I could embed eto controls (I’m thinking in rhino’s viewportControl) in a WinForms or a WPF project?

There is already a WinForms version of the ViewportControl. Just add a reference to RhinoWindow.dll and create a RhinoWindows.Forms.Control.ViewportControl object.

– Dale

oh… I didn’t know that. Now, I wonder if there is any “practical” reason for me, pretending to develop only for windows platform, to use ETO instead of extensively documented microsoft’s frameworks/librarys (?), i.e. winForms or WPF.

I mean, in the hipothetical case that I need to write Rhino’s specific forms like a dockable panel (are they “rhino specific”?) , Could I develop dockable panels using winForms or WPF?

I always have thought ETO was “the proper” way to go when developing UIs for Rhino.
With “proper” I mean the most feature rich in respect to Rhino UI. I admit this idea is not based on any particular experience, is just a deduction after watching people in the forum working with ETO. There must be a good reason for that, no? Why develop in ETO if a multiplatform plugin is not necessary? Just asking, I dont want to question anyone’s work…

It depends. If a GUI remains simple you should be able to make it work in Eto. I believe learning Forms and/or WPF helps and should be easily convertible.

When doing a complex GUI or commercial plugin I would target a specific platform, because I cannot test for Mac and it would mean an extra overhead to do so. Especially because Windows is still the major platform by far, regarding CAD you can skip that.
But this is my opinion…

So, referring Back to my question, could I write each and every Rhino UI element using WPF? And using winForms? If so, isn’t it more convenient to use ETO, as far as Rhino UI is build over this library?

I’d recommend Eto over Winforms or plain WPF.

Thank @nathanletwory, could you please elaborate that little bit? I mean, what are the reason for choosing ETO. Certainly there are good reasons, like documentation resources, to opt for a more widespread frameworks instead of ETO. If a client asks to me why I opted for ETO instead of winForm, I currently doesn’t have any strong reason to justify my decision… Just my current non-argued idea that “ETO is more convenient to develop Rhino UI’s”. But why?

Well, you said it yourself: Rhino UI is being more and more built on Eto.

1 Like

Dear Mr. Leceta,

I do not recommend developing a tool for other users, and limiting only to Windows. I think it makes more sense developing for users in any platform.


1 Like

It should be pointed out that on Windows we do use WPF and WinForms.

Eto is a library that uses WPF and WinForms to work with native user inteface elements on Windows. Eto also uses Cocoa to work with native user interface elements on Mac.

1 Like

But this means you’ll need to buy a Mac and test it on there as well. I wouldn’t ship a product, I not even opened at least once on this platform. Nevertheless starting on WPF and converting to Eto once its done, shouldn’t be a problem as it has been said.
Any GUI framework can be used. Its just a matter on how its gonna be invoked from Rhino.

You are right Tom, we would have to buy a Mac for @aitorleceta. We had to recently buy one for @IgorK too, so he could setup and test AR stuff in Reality Composer.

I’m totally fine with buying the team Macs for testing and to go have fun at the cafe. As long are they don’t use them for their core work it’s all good. We can’t afford working on slow hardware.