thanks for your feedback, we really appreciate it!
A “behavior” in the EyeX terminology is quite different from a XAML “behavior”, no doubt. But at the same time they are closely related because you often want to link one to the other. I’m glad to hear that you got an app up and running and that you read the developer’s guide as well — I hope that it could shed some light on what the EyeX behaviors are and how they work.
The GazeAwareElements sample shows how you can use a style with a property setter to decorate an element with the GazeAware behavior (EyeX behavior, that is). This creates an Interactor for the element behind the scenes. When the EyeX Engine sends gaze-aware events to the interactor, these are used to set the HasGaze property, and we can create a trigger to change the visual appearance of the element. All in XAML, no code behind.
The EyeX Framework for WPF in its current state is minimalistic by design. There are many ways it can be improved and some of these improvements are already on our backlog waiting to be implemented, for example, a smoother integration with popular MVVM frameworks such as Caliburn.Micro. Based on your feedback I think that we should also consider some improvements for the visual designer workflows. If anyone comes up with anything interesting along these lines, please let us know.
I’m not sure how many people actually use these tools though: calling them “traditional” might be an exaggeration. (So all you readers of this forum thread who want this feature: now is the time to post a “+1” reply!) At Tobii we don’t use these tools a lot but we do write XAML with MVVM, avoiding code behind, and we use the visual designer mostly to see what the control looks like as it is being written.