Trapping rotation events?

mikemayer67

Joined: 2012-01-10
Posts: 42

Posted: Fri, 2012-06-08 16:24

It was recently brought to my attention that I overlooked something when creating the emboss module... specifically rotation.

When a photo that has been embossed with an overlay is rotated, the overlay gets rotated with it.

I would like to make emboss somehow "aware" of rotations and proactively fix the overlay without forcing the user to turn off the emboss module, rotate images, turn the emboss module back on (the current work around).

I have tried reading through the gallery code and found the following:

in gallery/helpers/gallery_event.php as part of the rotate_ccw and rotate_cw menu items

Quote:

->ajax_handler("function(data) { " .
"\$.gallery_replace_image(data, \$('$item_css_selector')) }")

and in lib/gallery.common.js

Quote:

$.gallery_replace_image = function(data, img_selector) {
$(img_selector).attr({src: data.src, width: data.width, height: data.height});
$(img_selector).trigger("gallery.change");
};

Is there any way to detect/trap the gallery.change event/notification/etc that was triggered?

Feeling very confused.
mike

rWatcher

Joined: 2005-09-06
Posts: 722

Posted: Mon, 2012-06-11 18:40

There's a graphics_rotate and a graphics_rotate_completed event that triggers whenever a photo is rotated -- first one triggers before the rotate, second one triggers after the rotate is complete. You might want to look at the keeporiginal module, it uses the first event to backup the original version of a photo before it get's rotated.
http://github.com/rWatcher/gallery3-contrib/blob/master/3.0/modules/keeporiginal/helpers/keeporiginal_event.php

mikemayer67

Joined: 2012-01-10
Posts: 42

Posted: Tue, 2012-06-12 10:45

Thanks for the pointer... I'll take a look at that shortly.

mikemayer67

Joined: 2012-01-10
Posts: 42

Posted: Thu, 2012-07-26 02:18

I finally got some free time to take a look at keeporiginal to see what I need to do in emboss to catch/handle image rotations. This was exactly the pointer I needed to handle rotation events to properly re-emboss the photos. THANKS!

But... I quickly came to the realization looking through the entire keeporiginal implementation, that these two modules are probably very risky to have active at the same time. Both squirrel away a copy of the "original" for safekeeping. It is easy to imagine scenarios where one module clobbers the other's real original:

1) Neither module is installed.

2) Emboss is installed and activated. True originals are copied off to emboss's "originals" folder. Albums folder contains embossed images.

3) KeepOriginal is installed and activated

4) A photo is rotated (assume keeporiginal handles the rotate events first). KeepOriginal copies the embossed image to its "original" folder. Albums folder contains rotated image with rotated overlay. Emboss rotates the true original in its "originals" folder. Emboss creates a new copy in the albums folder an unrotated overlay

5) Emboss is deactivated. The rotated original is moved back to the albums folder

6) User performs another rotation on the image. KeepOriginal copies the embosssed image from its 'original' folder to the album folder

NO MORE UNEMBOSSED ORIGINAL!!!!

Are there any elegant solutions out there to make sure that two modules don't collide aside from warning users of the incompatibility?

I played around with the idea of failing activation or of turning off all functionality in emboss if it detects that keeporiginal is active... but this won't solve the problem if keeporiginal is activated after emboss has already begun making copies of the originals....

Any thoughts or lessons learned from others who have had to deal with "module collision?"

mikemayer67 Joined: 2012-01-10 Posts: 42	Posted: Fri, 2012-06-08 16:24
	It was recently brought to my attention that I overlooked something when creating the emboss module... specifically rotation. When a photo that has been embossed with an overlay is rotated, the overlay gets rotated with it. I would like to make emboss somehow "aware" of rotations and proactively fix the overlay without forcing the user to turn off the emboss module, rotate images, turn the emboss module back on (the current work around). I have tried reading through the gallery code and found the following: in gallery/helpers/gallery_event.php as part of the rotate_ccw and rotate_cw menu items Quote: ->ajax_handler("function(data) { " . "\$.gallery_replace_image(data, \$('$item_css_selector')) }") and in lib/gallery.common.js Quote: $.gallery_replace_image = function(data, img_selector) { $(img_selector).attr({src: data.src, width: data.width, height: data.height}); $(img_selector).trigger("gallery.change"); }; Is there any way to detect/trap the gallery.change event/notification/etc that was triggered? Feeling very confused. mike
	XUser login Username: * Password: * Create new account Request new password
rWatcher Joined: 2005-09-06 Posts: 722	Posted: Mon, 2012-06-11 18:40
	There's a graphics_rotate and a graphics_rotate_completed event that triggers whenever a photo is rotated -- first one triggers before the rotate, second one triggers after the rotate is complete. You might want to look at the keeporiginal module, it uses the first event to backup the original version of a photo before it get's rotated. http://github.com/rWatcher/gallery3-contrib/blob/master/3.0/modules/keeporiginal/helpers/keeporiginal_event.php

mikemayer67 Joined: 2012-01-10 Posts: 42	Posted: Tue, 2012-06-12 10:45
	Thanks for the pointer... I'll take a look at that shortly.

mikemayer67 Joined: 2012-01-10 Posts: 42	Posted: Thu, 2012-07-26 02:18
	I finally got some free time to take a look at keeporiginal to see what I need to do in emboss to catch/handle image rotations. This was exactly the pointer I needed to handle rotation events to properly re-emboss the photos. THANKS! But... I quickly came to the realization looking through the entire keeporiginal implementation, that these two modules are probably very risky to have active at the same time. Both squirrel away a copy of the "original" for safekeeping. It is easy to imagine scenarios where one module clobbers the other's real original: 1) Neither module is installed. 2) Emboss is installed and activated. True originals are copied off to emboss's "originals" folder. Albums folder contains embossed images. 3) KeepOriginal is installed and activated 4) A photo is rotated (assume keeporiginal handles the rotate events first). KeepOriginal copies the embossed image to its "original" folder. Albums folder contains rotated image with rotated overlay. Emboss rotates the true original in its "originals" folder. Emboss creates a new copy in the albums folder an unrotated overlay 5) Emboss is deactivated. The rotated original is moved back to the albums folder 6) User performs another rotation on the image. KeepOriginal copies the embosssed image from its 'original' folder to the album folder NO MORE UNEMBOSSED ORIGINAL!!!! Are there any elegant solutions out there to make sure that two modules don't collide aside from warning users of the incompatibility? I played around with the idea of failing activation or of turning off all functionality in emboss if it detects that keeporiginal is active... but this won't solve the problem if keeporiginal is activated after emboss has already begun making copies of the originals.... Any thoughts or lessons learned from others who have had to deal with "module collision?"

Trapping rotation events?

XUser login