- This topic has 14 replies, 11 voices, and was last updated 9 years, 4 months ago by
.
- Posts
Well, while I can program in C/C++ there simply is no reason in 2014 to program in it unless you are doing drivers or high performance code for games. 😉
So for all practical purposes, I am sure many people would be programming in C#/.NET on the Windows platform. (or in Java for cross compatibility)
So…. C# please.
If possible not a wrapper around the C++ code, because Interop is really slow when crossing the managed/unmanaged bridge. If it is possible at all a native implementation is prefered. But yeah, any implementation will work for now.
Hi, thanks for the feedback!
We have been considering a .NET/C# SDK package, but the big question is whether to go for WPF or WinForms, or both. We´d love to hear if anyone has any strong opinions there.
The Unity SDK package includes a C# wrapper that you can use to get started. There are some code samples in there as well.
My personal favorite is WinForms, because there is no need to artificially complicate things for no reason. WPF has its place on Windows Phone, because it is forced on us. If you do something that’s not possible in WinForms, you are probably designing it wrong and not keeping it simple and clean.
But there is no reason to decide for either WPF or WinForms, really, the API should be completely agnostic.
Actually it should be possible to use the API even from a service or a DLL. If there is an object that encapsulates the whole API and uses events to transmit it should not matter if the programmer uses WinForms, WPF or no window at all.
Actually for what I am trying to do I would need to use the API from a plugin DLL that gets called from another app that I have no control over. So it would be very bad if I need a window handle, because I can’t get one.
And I will definitely not have any form open, so I vote for: NEITHER. 😛
If you just mean as a sample, use WinForms. Minimal samples are always better and WPF is an unnecessary complication.
I totally agree that minimal samples are better. And since it seems that you’ll only be using data streams anyway, the question of which UI framework(s) to support isn’t very relevant for you.
But I do hope that developers of other applications, with regular windows to interact with the user, will find the interaction behaviors such as Activatable and Gaze-aware useful. And then they might appreciate some ready-made glue code for hooking up those behaviors to existing controls.
But that glue would have to be specific to the UI framework, of course. Which brings us back to the original question of which UI framework(s) to support. Anyone?
Hi All,
I prefer WPF; well since Microsoft introduced XAML, it’s recommended to immigrate to it. Not only it would be much easier to make the GUI by XAML, but also it would be Win8 App-ready.
Speaking as a former member of the WPF graphics team … MS is not really great at supporting / developing the teams that make their UI frameworks. Vicious internal competition produces a new internal tribe that self-promotes a new framework every few years. These things slosh around between devdiv and windows, with the managers stealing resources from each other and undermining each other’s efforts. I watched WPF get gutted between 2008 and 2011 (the three years I was there) because Silverlight was able to ship (low quality crap) more often. WPF has been on skeleton crew life support for years. It’s really ugly under the surface, a brittle monolith full of unfixable bugs. Some of the code clearly written as a joke. Silverlight is worse, the new windows xaml is just as bad. The old IE6 team (yes, it’s them) really lacks the discipline to make a solid product, so it’s just a huge pile of unstable shortcuts stacked on top of each other. I wouldn’t waste time investing heavily in it.
The new company reorg _might_ result in more cooperation than coopetition, and produce a stable and useful UI framework. Wait for that.
Until then, stick with things that people can easily dovetail in with their code – anyone worth their salt can write the UI glue to bind to data brought in by event handlers.
I did not want to start a UI flamewar, that’s why I did not say it like that.
But yes, you are right, WPF essentially is a feature loaded piece of crap. So if you have to choose, use WinForms.
WinForms are clean and to the point, they give easy examples. If someone has a WinForms example he can very easily do a WPF as well. In fact if you just create a non UI C# example anyone will easily be able to create either WinForms or WPF programs himself, its really trivial.
The only way I will ever pick WPF for a program is if you put a gun against my head. Otherwise… no thx. I stick with the stuff that works.
Also Windows 8 has never been adopted by the mass market, really, and never will be. So just stick with WinForms until Windows 9 comes along with a better UI framework.
Hi!
I vote for WPF – I really like XAML and WPF also for desktop applications.
But i hope to use to eyex independent from WPF, WinForms,… also for 3D applications.Hi,
Definitlty we need a .NET API in c# what ever the UI is WinForm of WPF. Personnally I am using WPF for a really long time now and it has nothing to do with WinForm, WPF is simply an other simple way to render UI, what I mean by simple is that when you catch the approach you cannot get ride of. A lot of developpers using c# are using WPF as well. WPF is a state of the art approach when you talk about databing, trigger and templating, simply try this with windForm and you will see.But Genraly it is not a UI matter but a simple API that is capable to work with both WinForm and WPF. Personnaly I will be frustrated if I have to re code something to get it working for WPF such dependency properties, notify property etc…
Go for a logical .NET API, in c# which can be used in a DLL
Agree with d.
Make it .NET and UI-technology independent, I want to use it even if I have a computer with two leds.
And make a Nuget-package please.That said, if I have to pick a technology mentioned above, I would say WPF, “alla dar i veckan”. In my experience, 99% of the times people prefer winforms before wpf its because they are much more familiar with winforms than wpf. I havent met a developer yet that really learned wpf good that has gone back to winforms*.
Also I’m sure thats its very usefel with a wpf/winform-specific lib that builds on top of that api, but I dont think that has to be from Tobii?Also 2, I dont know if wpf is a hack underneath as mentioned above, I just think its a really nice way of writing UI, especially when using MVVM-frameworks.
*without threats
Today we released the EyeX SDK for .NET, with code integration for both WinForms and Windows Presentation Foundation!
Please, check it out: go to Downloads page
Would it be possible to get the C# libs bundled up in a NuGet package (Henke suggested that above)? It looks like it’s possible to specify a custom license (like this Microsoft one has a license link on the left hand side).
- You must be logged in to reply to this topic.