6.0.0-git
2021-09-21
Last Modified 2009-07-17 by Michael Rubinsky

Michael Rubinsky

http://rubinskyfamily.com/mike

http://theupstairsroom.com

Ansel 2.0 Stuff

In no particular order, notes, todo, etc... that I've been accumulating:

Ansel 2.0 TODO:

PHP 5-ify ,getters/setters, clean up public,private distinction

Change Ansel_Storage::listImages() to accept a parameter array instead

of the gallery_id and the WHERE parameter. In addition, .need to refactor usage

of this method so that client code doesn't have to know anything about the SQL table

structure. i.e. get rid of the WHERE parameter. All non Ansel_Gallery code should be

calling Ansel_Gallery::listImages and not Ansel_Stroage list images....which leads to:

Make Ansel_Storage purely a class that Ansel_Image/Ansel_Gallery/Ansel_Tagger etc... use and NEVER client code.

list* methods should return ids, get* methods should return objects.

'namespace' all ansel js, output all strings in js and consolidate all the gallery_view js into a single *.js file

Refactor Ansel_Gallery to make it less dependent on the Share implementation for when/if Shares changes again.

(Maybe use composition instead of inheritance with the Share object).

Make it easier to add new ModeHelper objects. There should be an init function somewhere that

returns the available modes that are installed. Normal and Date should be 'built in' and always available - maybe parse the

contents of a special custom Mode folder?

Related to above, come up with a detailed idea of what a gallery "style" will be...clarify what a "mode" is vs a "style", how to allow for (and what to call) special modes (such as a possible "remote gallery") that cannot be arbitrarily switched between modes (like the current Normal and Date modes can be). Maybe a gallery "type" that is specified initially that cannot be changed (Local, Remote, etc...)? And, obviously along with all this, finally provide a UI (and backend support) to allow the user to define their own gallery styles. (Layout, color, thumbnail type etc..).

Allow user-specific, global, settings for what Ansel_Widgets are visible, allowing them to remove a widget that is defined in the style to un-clutter the view.

Modularize the photo (and maybe gallery) actions so we can easily plug in new actions, such as "Send this photo to Flickr" etc...

Maybe a "import/export" ability - to transfer images to other services like Flickr, Facebook, and import them from services that the user has perms to.

Layout ideas:

http://ajaxian.com/archives/cross-browser-inline-block

lazy load image thumbnails for some styles: Needs to be implemented on top of prototype...

http://www.appelsiini.net/2007/9/lazy-load-images-jquery-plugin

Horde_Image

Refactor Ansel_ImageData into Horde_Image - putting EXIF data extraction where it belongs.

Separate the Imagick and the convert driver into two separate drivers, getting rid of the imagick proxy stuff... DONE

Horde_Image needs to be able to support mulitple images/pages per image file instead of only single images so it can correctly deal with multipage resources like PDF and TIFF.

Provide the means to change the image type in Horde_Image after it's instantiated. This works easily using convert, but causes problems with imagick. This *might* resolve itself when the imagick and convert drivers are truly separate. Otherwise, resetting the internal imagick object might work.

Provide the means for executing explicit convert commands (like from effects) instead of having to build them up using various methods...and use tokens to specify where to put the input image and output image etc... this would allow complicated scripts that may have the images represented in the command more than once. DONE

Re-add a setStroke/setFillColor method, but just have them set instance variables instead of automatically adding to the convert command...then refactor the convert commands to not always have to unset the stroke/fill stuff after each H_Image method is processed.