Rather than use a slider value, you could create your own new dependency property to sync the other properties (via data binding). Bling doesn't use storyboards, rather, most of the time we just animate things at the same time, or when possible, create relationships
via databinding that are then influenced by an animation. First, you can just animate two properties at the same time, and they will just animate together (coincidentally but reliably); e.g.,
button.Right.Animate.To = canvas.Width; // animate button to end of containing canvas.
button.RenderTransform.ScaleXY.Animate.To = 2d; // animate button so that it is twice as large when reaching the end.
Alternatively, you can relate scaling to the right position of the button:
button.Right.Animate.To = canvas.Width; // animate button to end of containing canvas. button.RenderTransform.ScaleXY = 1d + (button.Right / canvas.Width);
If you want to synchronize the properties so that they move in sync, you can relate them to a nuetrual property (say a slider value):
button.Right = 0d + slider.Value * canvas.Width; // animate button to end of containing canvas. button.RenderTransform.ScaleXY = 1d + slider.Value;
slider.Value.Animate.To = 1d;
Actually, timeline animation is extremely limited and I'm 90% positive that the future of UI animation is through some form of physics. For a stick figure, for example, you can set a bunch of constraints on motion (e.g., joints) a long with goals..and you
have plausible movement via inverse kinematics. Bling has evolving support for UI physics with plenty of small demos, you can check out the distribution on the codeplex page for more details.
The lack of compile-time isn't such a big problem: if their is an error in your tree construction, you're code will often blow-up early in application execution rather than some indeterminite time in the future. Essentially, we now have 3 stages of error
checking to consider: compile-time, generation-time (essentially on application startup), and actual run-time. Generation-time errors are fairly easy to debug, as long as we focus on crafting good strings in the thrown exceptions (admittedly I haven't done
a great job here yet). Compile-time checking would be limited by the information available, of course, and I'm not confident that it could be powerful enough to reduce flexibility necessary in allowing for convenient tree constructions.
It almost makes sense to blow off compile-time checking completely and rely on generation-time checking. Combined with the fact that performance isn't much of an issue during code generation (as long as the generated code runs fast!), the lightweight DSL
approach used in Bling would be very well suited to a dynamic language such as IronPython or IronRuby. Still, C# seems good enough, and the added static type checking is great for things like good Intellisense.
On a related issue, debugging run-time errors is currently difficult because their is no current way to easily debug compiled trees in Linq/DLR. Hopefully, eventually we could match generated code with C# code used to create the generate code, but its a
huge meta problem (basically, we need to somehow propagate source locations...) and the eventual solution probably involves writing a parser.
The meta-argument is an interesting distinction. Or more generally, we could state that if a library/application interpret/translates an input tree to create behavior, then the language of the input is a DSL.
I would still think that LINQ was a DSL, since syntax was defined at that level, but it gets weird because additional semantics are defined by LINQ to SQL or LINQ to objects. Still, new syntax and semantics to me also indicates a DSL.
Yes and no. Blend 3 behaviors allow you to create a physical container and control high-level physical properties such as mass and gravity, and perhaps add springs and pivots between objects. This can be useful if you want some simple physical effects, but
it doesn't allow you to express the kind of constraints or inverse kinematics needed to use physics in a real UI. Bling allows you to express these constraints as expressions in C#, which would be much more difficult to express in XAML (which lacks its own
expression language) and therefore Blend.
To be perfectly honest, you are going to need to know/leverage a fair amount of trigonemetry and even a little bit of calculus to express many of the useful custom physical constraints, so it might be beyond designer-friendly right now (even if you could
write it down in Blend/XAML). This is just a fundamental limitation of any design tool: they can allow you to do simple things simply (as it should be!) but can't do much about the complicated things (e.g., complicated/dynamic animations, layouts, or physical
Right now, Bling aims more at the Processing and Flash/ActionScript audience, who are designers that are more technical, prototypers, or devs/researchers just playing around. I'm not really familiar with MVVM but...it
seems more like a strategy for long-lasting production code vs. UX prototypes (where you don't want to think too much about architecture/evolution). Most Bling programs start with a canvas and if data is involved (e.g., sample lab report data in a medical
reporting prototyping), we just bring it in as an after thought.
To clarify, I really enjoyed my interview with Erik. I have to admit my video skills aren't that great, so I think if it sounds a little rough, this was from my own inexperience vs. any probelm I had with the questioning.
As for the other comments:
XAML is not a full programming language, and completely lacks an expression language (hence the need for C#/VB code behind), while Bling is heavily based on getting the most out of expressions. We were able to hack some of Bling's features into XAML as
markup extensions, but this was not very effective (too many hacks), so we dropped it in the most recent version of Bling. You can always use Bling in a project that also uses XAML, Bling is a lightweight wrapper around WPF that won't interfere with your code
when you don't want to use it. That being said, if your WPF code is XAML-intensive, Bling might not be a good fit.
Translating C# code into HLSL and compiling it dynamically wasn't my idea, it was originally done by Brahma (http://brahma.ananthonline.net/), where they really are working on GPGPU tasks. I want to build a
version of Bling for DirectX 11, then we'll have easy access to compute shaders.
No Scala version of Bling, but Ingo Maier @ the EPFL is working on something called ScalaFX, which has a similar lineage (I worked with Ingo when I was at the EPFL, Bling comes from my experience in FRP).
If you use WPF the way it is promoted as being used (configuring mostly high-level widgets), you won't see the need for Bling at all. However, as soon as you want to do something that a high-level widget can accomodate (e.g., a custom data grid whose number
of visible rows/columns is determined by available space, or a 3D pie), Bling is very useful. Using databinding to express custom layouts is much easier than say...writing a new panel or composing other panels in intricate ways to get the desired layout (and
Bling makes expressing databinding less verbose).
Physical bindings actually solve the "Value Transition" problem really gracefully. Basically, what we do is create a binding of a specified strength less than 1 (e.g., .01 means, satisfy the constraint 1% on each time step). When its not changing, it will
basically stay the same, but when the target value changes, it will move relatively smoothly to the new value (for a time step of 30 milliseconds and a strength of 1%, it will take 3 seconds). Using something called "inverse kinematics" we can create value
transitions that are tweened via the physics engine but essentially wind up where we want them when we want them (imagine increasing the strength from 0 to 100% by the time where we want the transition to end). This is one of the reasons why physics is so
exciting to the future of UI.
WPF databinding is well designed and works fairly well, its just painful to write down complicated binding relationships (where verbosity = pain). This syntax problem is easy enough to fix though, without requiring any internal changes to WPF (Bling wraps