getScaledSize()

[peterchappy]

Would it be possible to add a getScaledSize() to the BaseView.h? I'm finding that I'm doing a lot of
exampleView->getWidth() * exampleView->getScale().value().x What do you guys think?

[benjaminbojko]

Hm yeah it's a bit of a PITA, but not sure if I'd want to add another method to BaseView, especially just for convenience. At some point in NASM I pushed for making scale, rotation, position, etc all Anim<T> properties instead of @Swiley's (much better) suggestion of having two separate methods like:

ci::Anim<ci::vec2>& getSizeAnim() { return mSizeAnim; };
ci::vec2 getSize() { return mSizeAnim.value(); };
void setSize(const ci::vec2& size) { mSizeAnim = size; }

I'm still intrigued by that approach but would worry about backwards compatibility. Any thoughts?

[peterchappy]

@benjaminbojko Now that we are versioning do we care about backwards compatibility?

[benjaminbojko]

Good point. What are your thoughts on splitting up getScale(), getScaleAnim(), etc.?

[peterchappy]

I think from a readability standpoint it makes sense (As in if you were new to the framework you might not know that you needed to call getSize().value()).
And not having to always call value() all the time would be nice too.

I was just talking to @kevinzak and he likes the idea of this change too.

[benjaminbojko]

Sounds good. @Swiley, @steinbergh, @shiwl: any objections?

[steinbergh]

@benjaminbojko 👍 i think this change makes sense, the only issue i would maybe have with it, is that it obfuscates, slightly, the fact that getSize() and getAnimSize() reference the same variable ultimately.

[benjaminbojko]

@steinbergh yeah agreed that it's a little confusing potentially. i'll do some testing around what happens if you simply change the value of a ci::Anim<T> and if that cancels the animation or not.

[Swiley]

I don't know if I love the idea of adding an extra call for every animation variable - scale, position, rotation, transform origin, background color, tint, alpha

I think it boils down to the original question of do we want to add convenience methods to the base view? I'd vote that I don't really want to do that in the hopes of keeping it as simple / easy to digest as possible, (I also understand the desire to not want to right .value(), but it just doesn't irritate me because I feel like it reinforces what kind of variable you're working with). I think these are preference reasons though, not a reason that something couldn't work - so it's probably best to be a team vote (or if @benjaminbojko gets the template going that might be good alternative!)

[benjaminbojko]

I just did some testing and there could be an alternative to all this, where we simply define operators to do math between an animation and the type it's wrapping. So instead of writing myAnim.value() * vec2(2.0f) you could do myAnim * vec2(2.0f).

I did a quick test and it seems to work well:

template<class T>
T operator + (const ci::Anim<T> & lhs, const T & rhs) {
    return lhs.value() + rhs;
}

template<class T>
T operator + (const T & lhs, const ci::Anim<T> & rhs) {
    return lhs + rhs.value();
}

template<class T>
ci::Anim<T> & operator += (const ci::Anim<T> & lhs, const T & rhs) {
    lhs = lhs.value() + rhs;
    return lhs.value();
}

template<class T>
T & operator += (const T & lhs, const ci::Anim<T> & rhs) {
    lhs = lhs + rhs.value();
    return lhs;
}

// ... repeat for -, * and /

Anim<vec2> a(vec2(2.0f));
vec2 b(vec2(4.0f));

console() << "a + b: " << (a + b) << endl;  // output: "a + b: [    6.000,    6.000]"
console() << "b + a: " << (b + a) << endl;  // output: "b + a: [    6.000,    6.000]"
console() << "a - b: " << (a - b) << endl;  // output: "a - b: [   -2.000,   -2.000]"
console() << "b - a: " << (b - a) << endl;  // output: "b - a: [    2.000,    2.000]"
console() << "a * b: " << (a * b) << endl;  // output: "a * b: [    8.000,    8.000]"
console() << "b * a: " << (b * a) << endl;  // output: "b * a: [    8.000,    8.000]"
console() << "a / b: " << (a / b) << endl;  // output: "a / b: [    0.500,    0.500]"
console() << "b / a: " << (b / a) << endl;  // output: "b / a: [    2.000,    2.000]"

My question: Is this actually helpful or would it be confusing for somebody coming in? Could this lead to unwanted side-effects? I'm pretty much 50:50 on this.