Support for rotation

[rohanmahale]

Support for rotation

[ihsanbal]

@rohanmahale this lines solved my rotation problem in CropView
` public void rotate(ROTATE rotation) {

    transform.reset();
    float degree = 0;

    switch (rotation.getRotationCode()) {
        case 0:
            degree = 90f;
            break;
        case 1:
            degree = -90f;
            break;
    }
    transform.postRotate(getRotation() + degree);
    bitmap = Bitmap.createBitmap(bitmap, 0, 0, bitmap.getWidth(), bitmap.getHeight(), transform, true);
    invalidate();
    resetTouchManager();
}

public enum ROTATE {
    RIGHT(0), LEFT(1);

    private final int i;

    ROTATE(int i) {
        this.i = i;
    }

    public int getRotationCode() {
        return i;
    }
}`

[eveliotc]

@rohanmahale as you might have noticed crop extension returns a Future so you can implement your callbacks/notification mechanisms on top of it, in example we use rxjava to wrap it and get notified when it completes (you can see how on https://github.com/lyft/scissors/blob/master/scissors-sample/src/main/java/com/lyft/android/scissorssample/MainActivity.java#L83-L89). Rotate was not part of our requirements, I agree it could be useful for third parties.

For both enhancement requests we don't have plans at this point but PRs are welcome :)

[eveliotc]

Renaming this for rotation only, callbacks ticket is now #23

[rharter]

My two cents: I think it makes sense for rotation to live in the loader, not the crop view. For instance, a Picasso Transformation can be applied that will rotate the image as needed before the CropView receives it.

I think that is ideal since rotation within the crop view will complicate the actual cropping (mapping of coordinates) and isn't the aim of the library.

[nathanjones]

@rharter I would agree that reading EXIF orientation data should probably be handled by the loader, a Picasso Transformation is perfect for that, but that's not necessarily the only time you would want to rotate an image.

In this issue, @rohanmahale wasn't entirely clear what his goal was, but rotation could mean having three buttons on an interface, one for rotate left, one for rotate right, and one to crop, which would usually finalize the image editing. That's definitely a useful feature, and a common pattern, but whether it's inside the scope of this library is the real question.

It would be nice to have certain extension features, like rotating, as separate gradle packages that could be included to extend the core functionality of Scissors.

[rharter]

@nathanjones I think the use case you're describing could be easily accomplished by using the image loader's transformation apis.

For instance, you could have your Picasso loader configured like so

public void rotateLeft() {
  rotation = (rotation - 90) % 360;
  reloadImage();
}

public void rotateRight() {
  rotation = (rotation + 90) % 360;
  reloadImage();
}

public void reloadImage() {
  cropView.extensions()
    .using(new PicassoBitmapLoader(Picasso.with(getContext(), new RotateTransformation(rotation))
    .load(url);
}

That being said, this doesn't allow for things like animating the rotation, so perhaps it does make sense to look at this if it's decided that it's in scope for the library. It might be as simple as applying a rotation or matrix to the canvas before drawing, and that might not be terrible considering the crop method draws with the same method onto a canvas.

[dschaller]

Thank you for you contribution to this repository.

Closing this contribution as this repository is being archived.