Easier transforming of images

[trych]

At the moment to transform an image b.transformImage(img, x, y, width, height) has to be used. All the b.itemX, b.itemWidth and so on commands cannot be used as setters, as only the frame will be transformed, not the image itself.

If I for example want to scale an image in place, I will have to get all four values just to do that: x, y, width, height. Same thing, if I want to move it to another position without scaling, I still have to get width and height first.

To make working with this easier we could either

1. Introduce methods like b.imageX(), b.imageY() and so on. Or simpler b.translateImage() and b.scaleImage() etc.

OR

2. (which I think would be better) Modify the behavior of b.itemX(), b.itemWidth() that they set the x, width etc. for both the image frame and it's contained graphic. In this scenario we would need to introduce a method to get the contained graphic somehow, in case this should be transformed by itself (which is a method I wanted to suggest anyways, as it can be very useful). So something like b.graphic(myImageFrame). This solution would keep everything clean in the sense that b.itemWidth() and b.itemSize() and so on can be used consistently for any item.

Thoughts?

[trych]

Ok, after thinking about this for a while now, version 1 does not make any sense to me anymore. I think version two is much cleaner and the way to go. Thus my suggestions:

1. Make all b.itemXXX() functions work for images, meaning treat any graphic as a child of its frame and transform it along.
2. Introduce some method to get the graphic of a frame, so it can be treated separately if the need arises. I would simply suggest b.graphic(frame).
3. Keep b.transformImage() for backwards compatibility reasons only. (Or we decide that the big new version 2.0 can break some compatibility and get rid of it altogether).

[b-g]

Hi @trych, many thanks for the thoughts! Here's my feedback:

1. OK + even better + good call!
2. I would rather name it then b. graphics (note the 's') and implement it analog to b.selections, b.words, b.stories
3. As we introduce dramatic new things with 2.0, I would strongly vote to get rid of legacy things

[trych]

Cool! I'm fine with getting rid of it, as it is rather confusing to have a separate function in the first place.