- 18/10/2014 at 03:03 #1862DwayneParticipant
As a front end dev I really enjoy working in XAML.
Now that I have read the early docs, looked through the samples and got my hands dirty with the EyeX SDK alpha as well as having a few things working in a simple WPF app, I find myself wondering a bit about the way the wrapper supports and exposes the “behaviors” and “attached/dependency properties”.
I realize there are developers that like to do all there UI work in the code behind and others like myself that spend more time in Blend and the XAML designer. For the folks that do not use Blend or the XAML designer much they may have a different take on the SDK’s XAML support, but I am finding the support a little awkward and not very design-tool friendly. Perhaps I am missing something or still need to make further environment tweaks.
For example, it appears that a “Setter” inside a style is necessary to make a control GazeAware. The GazeAware property dangles off of something called Behavior, but it doesn’t really seem to be a XAML “Behavior” per say.
Are there any plans to evolve to a more traditional style of support XAML before release?
Thank you, and great job on the alpha, working with this device is both very powerful and a ton of fun.20/10/2014 at 08:34 #1866AndersParticipant
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.21/10/2014 at 19:34 #1882AndersParticipant
Dwayne, and everyone else who is interested in this topic,
if you know any frameworks/components that could serve as good examples of the kind of tool support you’re asking for, we would be very grateful if you could share some links!
- You must be logged in to reply to this topic.