One of the surprising things that my 70-plus year old Mom commented to me was that my photo libraries lacked a slideshow functionality for ease of navigation. I developed my own image galleries prior to stumbling on this very new and very suave Picasa module. Back then, I developed my own slideshow engine as I built my own image gallery. Fortunately, Google upped the Picasaweb space to 1 Gig (and counting) and then this Picasa module came along.

I don't know how you would go about adding a slideshow feature for Picasa module but this is definitely a wish list. Picasaweb has a built-in slideshow feature but I don't know if that's exposed in its API.

I've made my silly JavaScript slideshow engine public though, if you would like some insights. I know you can definitely do better.

Slideshow engine: http://www.loloyd.com/blog/my_php_gallery_with_slideshow
Simple user-configurable slideshow example: http://www.loloyd.com/photosets/jeremy_8th_bday

CommentFileSizeAuthor
#8 picasa.module.tar_.gz193 byteslunatix

Comments

loloyd’s picture

Hmm... I realize there are no "previous" and "next" buttons either. This is a dev version and I hope I could contribute. Your code is nice and quite easy to hack/understand.

cyberswat’s picture

Assigned: Unassigned » cyberswat

I'm interested in what would be the best way to collect the data that could be used for both a slideshow and the previous/next buttons. Currently the module makes live calls to the Picasa API to get the information it needs to work with. The Picasa API provides all of the relevant data for an album at one time. I would like to explore hooking into Drupals node system to provide more flexibility and better search capabilities as well. I'm wondering if it would be best to modify the module to hook into Drupal cron processing to place the Picasa information into the Drupal database and accomplish many of these tasks at the same time.

Anonymous’s picture

Tracking.

I've been waiting for a mod like this for a long time and I think with the suggestions above, it will be the best photo gallery mod for Drupal.

Thanks for creating this.

cyberswat’s picture

Thanks ... I don't think it's going to be as useful as it should be until it fully integrates itself with Drupal's node system. At that point other modules can work with the images and help provide a true benefit to both developers and casual users. I've been working on a new version that treats the albums and images as nodes and hope to have it complete and ready for release by this weekend or next. I'm spending a good deal of time ensuring that the data from Google is translated and stored as nodes in the proper Drupal way. The next release still won't allow you to edit the information or images, but will be implemented in such a way that a future release will easily be able to utilize the rest of the Picasa api to allow for that type of integration.

More coming soon!

loloyd’s picture

A potential problem with Picasa Web is that it tends to give out a slow result when you request the feed of an album that contains so many pictures (I have 332 images in one of my albums). My webhost's PHP timeouts with a blank when I browse it at home with a slow connection but lags when I browse it at the office with a faster connection. Of course, one way to mitigate this kind of problem is to limit the number of images your Picasa Web albums contain, sort of making a series like "Album 1 Part 1", "Album 1 Part 2", etc.

Another way to mitigate this issue AND hopefully help the effort in making the slideshow function is to cache the resultant feed in Drupal's database. And then work with that temporarily, say, for a given session or for a given server time frame - until such a time when it would be considered logical to refresh this cache's contents. Btw, am I right to say that the feed getter is function picasa_parse_rpc($loc)? This would mean that the last time the content was cached should also be stored in Picasa's data store in the Drupal database. This would definitely SPEED up the performance of your Picasa module because it would lessen the number of times it requests for feeds. In addition, we can then easily navigate through our albums with relative ease and convenience since we always know how many albums are there, how many images are there, and what available images are there - with cached data from the Drupal database. We can actually get crazy with the navigation!

A hook with Drupal's cron to update the whole Picasa feed library would also be a nice idea.

The problem is that I know the idea but I don't know how to do it all in PHP, moreso in Drupal's framework.

babaker’s picture

At least if I've understood cyberswat's previous posts, I think the proposed idea is to have a cron job that would fetch the albums and generate drupal nodes for the images. This would then stop any server timeouts that you are having because the data that the user would see would be drupal nodes instead of having to read in and parse the gdata. Once the items are in nodes, I would imagine it would be simple to add slideshow functionality, along with previous and next functionality as well.

It would probably be wise to allow each user the ability to specify how often the cron job is run and cache refreshed, so that those with albums that are not updated often don't keep running a refresh for no reason. Perhaps the ability to turn off the cron and manually refresh the feed would be beneficial as well.

babaker’s picture

Would it be possible to extend the functionality of the image module for what we're trying to do? perhaps the picasa module could recreate the same structure that is created when setting up a traditional gallery. Like instead of storing the file path for each image, store the url to the thumbnail or original image. Theoretically, I would think that then you could have Picasa gallery images seamlessly alongside other images that might be uploaded to the site, and perhaps even use the modules that exist already to attach images to other nodes. Any thoughts?

lunatix’s picture

Title: Slideshow Functionality » Slideshow Functionality using lightbox
StatusFileSize
new193 bytes

I have modified the module to use Lightbox (http://www.huddletogether.com/projects/lightbox2/). I have attached the modified module. I didn't integrate this with the lightbox module (yet). I just downloaded the lightbox scripts and placed them in my theme.

I also had to modify my page.tpl.php, I added this in the head:

	<link rel="stylesheet" href="<?php echo base_path() ?>themes/tck/lightbox/css/lightbox.css" type="text/css" media="screen" />
	<script type="text/javascript" src="<?php echo base_path() ?>themes/tck/lightbox/js/prototype.js"></script>
	<script type="text/javascript" src="<?php echo base_path() ?>themes/tck/lightbox/js/scriptaculous.js?load=effects"></script>
	<script type="text/javascript" src="<?php echo base_path() ?>themes/tck/lightbox/js/lightbox.js"></script>

I actually don't know if using the base_path() method is the best way to go.

In the near future I will try to get it working with the lightbox module and make a setting available for enabling/disabling this functionality.

Cheers Armand

loloyd’s picture

Nice work, lunatix.

Going back to the "issue" of trying to hook Drupal's node system to each picture hosted by Picasaweb, I don't think that would be a good idea. Depending on users and websites, some pictures (and hence their IDs) may have different persistencies when compared to nodes. I envision this would entail a nightmare in congruency checking, especially if some of our Picasa albums are updated on a periodic basis by the addition or subtraction of pictures. I am just thinking on a theoretical level anyways.

Ultimately, this is just a vote against hooking Drupal's node system to each Picasaweb picture. Although, I submit that hooking the node system to each Picasaweb album would be a more practical and realizable approach.

lunatix’s picture

Title: Slideshow Functionality using lightbox » Slideshow Functionality

oops, I noticed that I changed the topic title. I changed it back.

cyberswat’s picture

I've been coding away at a new version of the module and am getting close to being able to create a cvs branch for everyone to evaluate. This may be a long post as I try to address each of the questions above.

Slideshows

This is the number one requested improvement for this module. I firmly believe the best way to handle this is to not handle it :-) ... There are several modules out there that are already designed to work with nodes and display them as a slideshow. The only reason the pre-existing modules can not work with the current version of the Picasa Module is the information is not stored as nodes. I'll touch a bit more on why the images, albums and users should be stored as nodes in a moment. It is of my opinion that additional slideshows or functionality that enhances one of the slideshow modules should be contributed to those modules and that the Picasa Module should use Drupal's framework to allow seamless integration.

I know next to nothing about these modules, but here are some samples:

In addition to these there is a Google powered slideshow that is available from the Picasa website when browsing an album. I think that the Picasa module should implement this particular slideshow as an option. My initial thoughts are to use the thickbox module to display the slideshow http://drupal.org/project/thickbox but I have not hit that point in the new development.

Comment #1

Google's Picasa API stores a plethora of information that is not available in the current version. One such item is a sort index that would place the images in the same order as the Picasa website. It is possible to create custom functionality for next/previous by evaluating these indexes. This would lock the order to what is in place on the Picasa website. By creating the picasa, picasa_album, and picasa_user node I am able to record not only these indexes, but a wealth of other information including exif tags, comments, etc.

In addition, once the Picasa module stores it's information as nodes there are that may assist:

Comment #5

This is handled 100% by not relying on improting a users data as nodes. 300+ nodes per album is a modest number that Drupal can handle without problem. 300+ calls to a remote server is more intensive and prone to failure. The new method of displaying an albums page will likely integrate with the Views module http://drupal.org/project/views providing an extremely robust method of creating not only the default album views, but highly customizable views. The idea will be to allow the site administrators to define exactly how they want the users, images, and albums to display. This combination not only utilizes Drupal's internal caching mechanisms, but also each site admin to fully customize navigation paths through the data.

Comment #6

As it stands now (in the new development) each user with the proper role has a new tab when they click on "My Account" with the title "Picasa" ... when the user clicks on the Picasa module it prompts them for the Picasa username to use. After that information is in the system the user can click on a "Synchronize" button that will synchronize that users data. Each node type (picasa, picasa_image, picasa_album) is tagged with a unique id by Google. This allows us to create a single node for an item and then allow revisions by using the node's id and the google id. I can imagine a point where an administrator would want options to control how a user is allowed to perform a synchronization. These options would tie into the cron runs. As it stands now, the admin options are not in the code but I could add them if everyone thinks it is relevant for the next release.

Comment #7

The difference between a regular image and the Picasa images is the quantity of associated data. For this reason I think it makes more sense to use new node types instead of the ones created by the image module. Even though the nodes will have different structures it will be possible to create views that can include both image and picasa_image node types in the same results.

Comment #8

Great work. Perhaps it would make sense to provide an administration option that detects the lightbox module and reacts accordingly. The best way of providing this type of integration is to do it in a way that will allow it to function without requiring theme modifications. The Javascript you post can be added dynamically from the modules code base. It sounds like you are on this path already ... please understand that by the next release of Picasa you will be working with nodes instead of the existing picasa images.

The function I believe you were looking for regarding the path to theme is http://api.drupal.org/api/5/function/path_to_theme

Comment #9

The revisioning is handled by the combination of the node's id and another id provided by Google. The combination of the two id's allows us to create a single node that is assigned to an image for the life of that image. The node's id does not change in subsequent synchronizations with Picasa. Before each synchronization a list of existing imported items is created and items that have been removed since the last synchronization are accounted for as well.

General Thoughts

I've been in communication with many Drupal developers regarding the issue of using Drupal's node system. In short, the best way to utilize the Drupal framework and the work of other developers is to list each item as a node. Each image and album has a lot of info stored with it. An admin interface would be provided to check off which pieces a particular site wanted to display. Each piece of displayed content is included in Drupal's search mechanism. This will allow users to perform advanced searches along the lines of "show me all of this users photos that were taken with a Nikon using this shutter speed" ... the searches could be as advanced or simple as the site administrator wants. Going this route provides infinite possibilities and will stop the Picasa module from bringing down a site if it can't communicate with the Picasa API for whatever reason.

That being said, it may be desirable for a site administrator to use the existing live xml_rpc calls. I honestly believe it is bad practice having the live calls, but would be willing to provide an admin option that will switch between live calls and importing as nodes if that is what the community wants.

Hope that helps bring everyone up to speed with the direction of this module. I'm working on the code every free moment and plan on committing changes in the near future. I'm convinced these changes are going to really make the Picasa module a quality product.

cyberswat’s picture

Status: Active » Closed (fixed)

FOr now this has been shifted back to Google to handle ... version 5.x-3.1 provides slideshows although it is not an ideal solution just yet.