Forums

I don't have an iPad around but I have tested it in my iPod touch and it works, although a little bit slow. It may be that the resize controls in the SAM skin are a bit small for a touch device.

When I developed the widget I started by copying the YUI2 functionality and it didn't support resized images. I think we can do better, yes. I was thinking about writing an example that did just that: sort of a little image editor. One option would be to add a state that hides/shows the crop controls (mask, resize, etc). Ie: press a "crop" button, show the ImageCropper controls, press enter/a "done" button, hide the ImageCropper controls, execute the crop.

Executing the crop action can be tricky. Using "overflow: hidden" in the boundingBox and moving the image around is something I've been meaning to test. Do you have any specific ideas as to how to implement it?


PS: now that you mention touch devices I'm getting more convince that keyboard support should be loaded on demand. What do you think about that?

Hi,

My ideas on how to implement this:

Keyboard support on demand makes total sense. No-one will use a keyboard for this when he has a mouse. I think the trick is to make the functionality on a mobile device work in a way that is "natural", which is a little different from the regular mouse-style interaction.

I can see two ways to activate the crop action:
1. by activating the "select function" and having the default selection square become visible.
2. by activating the "select function" and the mouse change to a Plus and allowing you to click drag a selection square. This is more in line with how image manipulation tools work but or a consumer might be less intuitive.

Executing the crop action should probably lead to some hidden temporary canvas be loaded with the results and and loading that back to the active canvas. One might even think of a canvas as a Photoshop layer (with transparency options etc.). Executing a crop or other action could conceptually then be just creating a new layer and deleting the old. It would also allow you to "undo" actions.

If you separate "select" from the crop action, you can also create other actions:
copy, move, delete, scale, transparency, rotate, transform, filter etc. So Select first then select Action
Or one could link the "select function" to a particular action and have the select square have a different look and function depending on the selected Action. So Action first. E.g. a constrained scale action should allow you to just manipulate the corners.

These Actions could be Plugins.

The use case that I'm personally interested in:
* Upload an image
* Crop, Scale, Move the image
* Save the resulting image

Well, honestly I am not sufficiently aware of alternatives. I assumed canvas was the way to go (drag and drop, upload photo, save photo) etc

I was just checking we where on the same page.

Using <canvas> simplifies a lot. It should just work with the current implementation. Load the image into a canvas with getImageData(), do whatever you want with it, use canvas.toDataURL() and set the result as the "source" attribute of the widget.

Cool!