From album@h... Wed Jan 5 07:14:34 2005 From: album@h... (Dougie Nisbet) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Google interpretation of album pages Message-ID: <41DC045A.6040905@highmoor.co.uk> I was looking to see if any of my albums came up on google and it looks as if the google 'bots don't do anything neat with the pages they find. There appear to be plenty matches http://www.google.co.uk/search?hl=en&q=site%3Ahighmoor.co.uk&btnG=Google+Search&meta= but nothing particularly meaningful appears in the listing. I don't remember it always being like this. Has something changed with google? I've a feeling it used to take the description from the title but now it seems to be taking it from the pathname. Dougie From album-author@d... Wed Jan 5 12:17:22 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Google interpretation of album pages In-Reply-To: <41DC045A.6040905@highmoor.co.uk> References: <41DC045A.6040905@highmoor.co.uk> Message-ID: > I was looking to see if any of my albums came up on google and it looks > as if the google 'bots don't do anything neat with the pages they find. > There appear to be plenty matches > > http://www.google.co.uk/search?hl=en&q=site%3Ahighmoor.co.uk&btnG=Google+Search&meta= That's very strange. If I search for just a page on your site: http://www.google.com/search?q=%22Ducks+at+that+that+Arty+Craft%22 It doesn't have any of the text. But if I search for one of my pages: http://www.google.com/search?q=%22kodi+takes+down+a+cow%22 I see the text. It may be that you have very little text/captions on your pages?? Is anyone else seeing this? Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From leah@u... Mon Jan 24 17:37:22 2005 From: leah@u... (Leah Cunningham) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Album truncates directory captions Message-ID: <20050125013721.GG5058@unleashed.org> Hello, I am running the Album script 3.07 and am having a hard time figuring out how to modify the allowable length for a directory caption. I don't seem to have this problem with image captions, but when I used captions to list out multiple image directories, even though there should be pleanty of space, I get something like: Folders: September - Misc and..road trip unfinished October - Osceola to..o (Leah's home town) October - Misc unfinished November - Misc and ..nksgiving unfinished November - ALS2001 San Francisco December - Winter ho..ay in UK and Ireland I thought it was my theme at first, but I see the same thing running without any themes at all. I got into this mess in the first place because the newer versions of Album insert a
in directory listings when there is an "_" character, so I thought I'd try captioning instead, but now am running into this problem. Any help on either of these problems? Leah -- Must not turn into a snake. It never helps. -------------------------------------------------- Leah R. M. Cunningham | (heinous)@freenode #suse www.heinous.org | Linux geek, et al. -------------------------------------------------- From album-author@d... Tue Jan 25 00:37:42 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Album truncates directory captions In-Reply-To: <20050125013721.GG5058@unleashed.org> References: <20050125013721.GG5058@unleashed.org> Message-ID: > ..having a hard time figuring out how to modify the allowable length > for a directory caption. Not all options for album are immediately apparent from the usage so as to keep the basic usage page from getting too big. So: % album -h Gives the most immediate options. % album -more Gives more options (as mentioned in 'album -h'). And finally: % album -More To see it all (mostly). The option you want is in 'album -more': -name_length Limit length of image/dir names [40] > because the newer versions of Album insert a
in directory > listings when there is an "_" character, so I thought I'd try It should be inserting a space, not a
- you might see the HTML wrap on the space depending on the theme formatting. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From leah@u... Tue Jan 25 10:24:02 2005 From: leah@u... (Leah Cunningham) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Album truncates directory captions In-Reply-To: References: <20050125013721.GG5058@unleashed.org> Message-ID: <20050125182401.GH5058@unleashed.org> David Ljung Madison (album-author@daveola.com) [050125 00:42]: > The option you want is in 'album -more': > > -name_length Limit length of image/dir names [40] Thanks, I was hoping it was something obvious. I was about to start looking at the script, but it was a long day yesterday. > It should be inserting a space, not a
- you might see the > HTML wrap on the space depending on the theme formatting. I tried this with and without a theme, so not sure, but it looks like: 2003-01
jan LWNY
2003-01
jan misc
2003-02
hair car and ice storm fun
Somehow I'm getting a
tag in the middle of my links where the directory names were: 2003-01_jan_LWNY 2003-01_jan_misc 2003-02_hair_car_and_ice_storm_fun -- Must not turn into a snake. It never helps. -------------------------------------------------- Leah R. M. Cunningham | (heinous)@freenode #suse www.heinous.org | Linux geek, et al. -------------------------------------------------- From album-author@d... Tue Jan 25 19:46:44 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Album truncates directory captions In-Reply-To: <20050125182401.GH5058@unleashed.org> References: <20050125013721.GG5058@unleashed.org> <20050125182401.GH5058@unleashed.org> Message-ID: > > It should be inserting a space, not a
- you might see the > > HTML wrap on the space depending on the theme formatting. > > border='0' /> size='-1'>2003-01
jan LWNY
> > Somehow I'm getting a
tag in the middle of my links where the > directory names were: > > 2003-01_jan_LWNY Right - there is a feature in album that finds dates in directory and image names and prints them "Pretty" so they are a little more readable. You're getting a
after the '2003-01' date, but not just because you're using '_' in your directory name. If you don't want this, then change your theme to not use Pretty(), by changing lines like: <:=Pretty(Name($save),1,1):> to: <:=Name($save):> If there's enough clamoring for this, I might make it an option, but I have a feeling the "Pretty" printing will become an album module, so it will be easier to select/deselect it in the future. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From album@d... Wed Jan 26 02:40:01 2005 From: album@d... (Jon Daley) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Album truncates directory captions In-Reply-To: References: <20050125013721.GG5058@unleashed.org> <20050125182401.GH5058@unleashed.org> Message-ID: > On Tue, 25 Jan 2005, David Ljung Madison wrote: > > If there's enough clamoring for this, I might make it an option, but > > I have a feeling the "Pretty" printing will become an album module, > > so it will be easier to select/deselect it in the future. > > I always disable this as well. > > ************************************************************** > * * To say America can have * > * Jonathan M. Daley * strong leadership without * > * * strong character is to say we * > * jondaley@snurgle.org * can get water without getting * > * * wet. * > * www.snurgle.org/~jondaley * -- J. C. Watts * > ************************************************************** From leah@u... Wed Jan 26 11:28:18 2005 From: leah@u... (Leah Cunningham) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Album truncates directory captions In-Reply-To: References: <20050125013721.GG5058@unleashed.org> <20050125182401.GH5058@unleashed.org> Message-ID: <20050126192818.GK5058@unleashed.org> David Ljung Madison (album-author@daveola.com) [050125 19:55]: > Right - there is a feature in album that finds dates in directory > and image names and prints them "Pretty" so they are a little more > readable. You're getting a
after the '2003-01' date, but not > just because you're using '_' in your directory name. > > If you don't want this, then change your theme to not use Pretty(), > by changing lines like: > > <:=Pretty(Name($save),1,1):> > > to: > > <:=Name($save):> I can't find any "Pretty" lines in my theme. I'm just using the BigMaste theme. -- Must not turn into a snake. It never helps. -------------------------------------------------- Leah R. M. Cunningham | (heinous)@freenode #suse www.heinous.org | Linux geek, et al. -------------------------------------------------- From fbax@s... Thu Feb 3 09:12:54 2005 From: fbax@s... (Frank Bax) Date: Thu Dec 21 19:59:32 2006 Subject: [Album] Modifying a theme Message-ID: <5.2.1.1.0.20050203120136.0381eec0@pop6.sympatico.ca> My Album contains only subdirectories, so I want to modify "Blue" them to remove "More...". The code looks like I should be able to simply comment out the line: @More = ("$PATH/More.gif", 120, 42); When I tried this, "More..." goes away, but captions are no longer aligned with images. Frank From album-author@d... Thu Feb 3 12:04:09 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Modifying a theme In-Reply-To: <5.2.1.1.0.20050203120136.0381eec0@pop6.sympatico.ca> References: <5.2.1.1.0.20050203120136.0381eec0@pop6.sympatico.ca> Message-ID: > @More = ("$PATH/More.gif", 120, 42); > ...but captions are no longer aligned with images. All the simmer themes run through thumbnails for each line first and then the captions - this is for layout reasons. So there is a blank cell underneath More that needs to be removed. This was fixed in the simmer_theme 3.02, though I unfortunately didn't run it on all the themes. I'll be releasing a new theme package with the next album release, so you can wait for that, or else you can remove this line: <:= "\n" unless Get($save,'num') :> Or change it to the more correct: <:= "\n" unless !@More || Get($save,'num') :> Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From fbax@s... Fri Feb 4 09:43:01 2005 From: fbax@s... (Frank Bax) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Some questions about album console output Message-ID: <5.2.1.1.0.20050204122621.03e3c680@pop6.sympatico.ca> A few questions (see shell session below): 1) What happened to leading slash for $HOME? 2) JonesAlbum/album.conf is really ./album.conf! 3) Why does Jones.E2 produce WARNING? 4) Why does Jones.E2 not read JonesAlbum/album.conf? 5) Jones.E2 was presented without a theme until I ran album with no args. Why? $ pwd /var/www/htdocs/album/JonesAlbum $ find . | grep conf ./album.conf $ cat ./album.conf theme BlueNew # command-line saved option medium 640x480> # command-line saved option index index.html # command-line saved option theme_path /var/www/htdocs/album/JonesAlbum/Themes/ # command-line saved option theme_url /Themes # command-line saved option $ cat /home/fbax/.album.conf theme_path /var/www/htdocs/album/JonesAlbum/Themes/ # command-line saved option ffmpeg . # command-line saved option theme_url /Themes # command-line saved option $ album -depth 1 Read conf: home/fbax/.album.conf This is album v3.07 Read conf: JonesAlbum/album.conf Images: JonesAlbum [XXXXXXXXXXXXXXXXXXXX] $ album Jones.E1 Read conf: home/fbax/.album.conf This is album v3.07 Read conf: JonesAlbum/album.conf Images: JonesAlbum/Jones.E1 [XXXXXXXXXXXXXXXXXXXX] $ album Jones.E2 Read conf: home/fbax/.album.conf [album] WARNING: -theme_url still requires -theme option, it doesn't replace it This is album v3.07 Images: Jones.E2 [XXXXXXXXXXXXXXXXXXXX] $ album # This fixed the problem!?! From fbax@s... Fri Feb 4 06:43:01 2005 From: fbax@s... (Frank Bax) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] .not_img vs .no_album Message-ID: <5.2.1.1.0.20050204093959.050d3030@pop6.sympatico.ca> I don't understand the difference between ".not_img" and ".no_album" when applied to a file. They both appear to have the same effect. From album-author@d... Fri Feb 4 12:05:29 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Some questions about album console output In-Reply-To: <5.2.1.1.0.20050204122621.03e3c680@pop6.sympatico.ca> References: <5.2.1.1.0.20050204122621.03e3c680@pop6.sympatico.ca> Message-ID: > 1) What happened to leading slash for $HOME? Fixed already in the next release. > 2) JonesAlbum/album.conf is really ./album.conf! It prints the .conf according to it's path from the top of your album. > 3) Why does Jones.E2 produce WARNING? That also has been handled better in the next release. > 4) Why does Jones.E2 not read JonesAlbum/album.conf? Much more interesting. First of all, the clue is in the diff between E1&E2: > $ album Jones.E1 > Images: JonesAlbum/Jones.E1 [XXXXXXXXXXXXXXXXXXXX] > ... > $ album Jones.E2 > Images: Jones.E2 [XXXXXXXXXXXXXXXXXXXX] It doesn't realize that Jones.E2 is part of your JonesAlbum. So it's not reading JonesAlbum/album.conf. You need to make sure you build it either by building without -depth 1 or by using -add so that it becomes part of JonesAlbum. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From album-author@d... Fri Feb 4 12:12:37 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] .not_img vs .no_album In-Reply-To: <5.2.1.1.0.20050204093959.050d3030@pop6.sympatico.ca> References: <5.2.1.1.0.20050204093959.050d3030@pop6.sympatico.ca> Message-ID: > I don't understand the difference between ".not_img" and ".no_album" when > applied to a file. They both appear to have the same effect. http://MarginalHacks.com/Hacks/album/Docs/Section_4.html#Whats_the_difference_between_.no_album_and_.hide_album_and_.not_img Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From album-author@d... Fri Feb 4 14:16:56 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] .not_img vs .no_album In-Reply-To: References: <5.2.1.1.0.20050204093959.050d3030@pop6.sympatico.ca> Message-ID: > http://MarginalHacks.com/Hacks/album/Docs/Section_4.html#Whats_the_difference_between_.no_album_and_.hide_album_and_.not_img Actually, ignore this URL. I'm getting rid of this part of the docs as this has a much better explanation: http://MarginalHacks.com/Hacks/album/Docs/Section_2.html#Hiding_Files_Directories Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From c.jahn@g... Sun Feb 13 09:49:21 2005 From: c.jahn@g... (Carsten Jahn) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Sorting by file date / time Message-ID: <200502131849.21737.c.jahn@gmx.de> Hello All, I tried to sort the thumbnails in my index pages not by file name, but by date and time, using the -date_sort flag. My whole command line is: album -no_image_loop -date_sort -no_crop -exif_image "
Date: %Date/Time%
Resolution: %Resolution%, ISO: %ISO equiv.%, Focal length: %Focal length%, Aperture: %Aperture%, Exposure Time: %Exposure time% (%Exposure%), Flash: %Flash used%" -index index.html However, the -date_sort does not show any effect; files are sorted by file names anyhow. I'm using Debian linux, my locale seems to be English. An example output of date is: ?Sun Feb 13 13:32:53 CET 2005 ?(it is possible to have lots of standard commands print their output in German, but I don't use this). Does anyone have experiences with the same problem? Thanks in advance! Carsten From album-author@d... Sun Feb 13 14:49:12 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Sorting by file date / time In-Reply-To: <200502131849.21737.c.jahn@gmx.de> References: <200502131849.21737.c.jahn@gmx.de> Message-ID: > I tried to sort the thumbnails in my index pages not by file name, but by date > and time, using the -date_sort flag. My whole command line is: -date_sort does *not* sort by EXIF date, it sorts by file modification time. Trying touching one of the images, run again and see if it goes to the end of the list. Also be sure to specify the version of album you are using. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From album@h... Wed Feb 16 00:30:10 2005 From: album@h... (Dougie Nisbet) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Sorting by file date / time In-Reply-To: References: <200502131849.21737.c.jahn@gmx.de> Message-ID: <42130492.8020902@highmoor.co.uk> David Ljung Madison wrote: >>I tried to sort the thumbnails in my index pages not by file name, but by date >>and time, using the -date_sort flag. My whole command line is: >> >> > >-date_sort does *not* sort by EXIF date, it sorts by file modification time. > >Trying touching one of the images, run again and see if it goes to the end >of the list. > >Also be sure to specify the version of album you are using. > >Dave > >--------------------------------------------------------------------------- >Dave Ljung Madison http://GetDave.com/ 415 341-5555 >------------ "Preferred over shiny round objects 2-to-1" ------------------ > > >_______________________________________________ >Album mailing list >Album@marginalhacks.com >http://marginalhacks.com/mailman/listinfo/album > > > I've noticed the same problem as Carsten. When I read your email I decided to do a few experiments and I still can't get the order of the images displayed to change. In my sparrowhawk (http://snipurl.com/ckuw) pictures the series of images were taken over the space of just a couple of minutes. I was trying to get them in date chronological order; i.e. the oldest (albeit just by seconds) pictures at the beginning of the page. I've used the following command with variations/experiments of adding/removing '-date_sort' and '-reverse_sort' and nothing make any difference to the order. /usr/local/bin/album -medium 800x600 -date_sort -reverse_sort -exif "%Camera model%
%Date/Time% %Exposure time% %Aperture% Flash: %Flash used%" -known_images -no_crop -file_sizes -clean Sparrowhawk\ -\ 6Feb2005/ The newer photographs have the newest file stamps. Just to ensure that the file modification time accurately reflected the time the photograph was taken I ran jhead -exonly -ft * in the image directory. This changed the filestamps accordingly. I did another few test runs of album and the image order stays the same; newest image first. This is album v3.01 running under Debian. Dougie From album-author@d... Wed Feb 16 02:21:44 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Sorting by file date / time In-Reply-To: <42130492.8020902@highmoor.co.uk> References: <200502131849.21737.c.jahn@gmx.de> <42130492.8020902@highmoor.co.uk> Message-ID: > decided to do a few experiments and I still can't get the order of the > images displayed to change. In my sparrowhawk (http://snipurl.com/ckuw) I just ran "HEAD" on the full size images at your site and grepped out the Last-Modified times and saw: Last-Modified: Mon, 07 Feb 2005 11:34:08 GMT Last-Modified: Mon, 07 Feb 2005 11:33:58 GMT Last-Modified: Mon, 07 Feb 2005 11:33:48 GMT Last-Modified: Mon, 07 Feb 2005 11:33:37 GMT Last-Modified: Mon, 07 Feb 2005 11:33:26 GMT Last-Modified: Mon, 07 Feb 2005 11:33:16 GMT Last-Modified: Mon, 07 Feb 2005 11:33:05 GMT Last-Modified: Mon, 07 Feb 2005 11:32:54 GMT etc... Looks sorted to me. It's likely with digital cameras that name sort and date sort will coincide. If you're having trouble with -reverse_sort, please consider updating, there have been many releases since 3.01. Finally, there *is* an issue with mixing -name_sort and -date_sort that can be repaired by editing the album.conf. This has been fixed in v3.10, which is so damn close to done I can taste it! Argh! I solved the configuration issues, and now I just need to cleanup the setup code and then release it with plugins. I should find some time off work in a couple weeks. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From dave@s... Tue Jun 7 13:10:44 2005 From: dave@s... (Dave Hansen) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] [PATCH] recurse to find directory thumbs Message-ID: <1118175044.28460.31.camel@localhost> I quite like the new (to me) dir_thumbs feature. However, I have some directories laid out like this: album/foo/a/pic1.jpg album/foo/b/pic2.jpg Where foo/ only contains a/ and b/. When I look at album/, I only get a text entry for foo/ and I'd really like to get a thumbnail from foo/a or foo/b, instead. The appended patch calls dir_image() recursively if the current directory has no pictures of its own, but does have children. It also adds a new album.conf option: "dir_thumb" which can be used to pick an individual picture from a directory without relying on captions.txt. This is so I can have a dir_thumb which is not the first picture in order. I like to pick some from the middle on occasion. dir_thumb can also specify a directory: # album/foo/album.conf dir_thumb b/ This isn't the cleanest implementation in the world, but it will probably give you an idea whether it's something you'd like to add, and I don't think it's too horribly intrusive. I'd be happy to clean it up a bit if you'd like to integrate it. -- Dave --- /home/gone/bin/album 2004-12-31 01:24:04.000000000 -0800 +++ album 2005-06-07 12:52:51.000000000 -0700 @@ -82,6 +82,7 @@ add_option(1,'Album Options:',$OPTION_SEP); add_option(3,'image_pages',$OPTION_BOOL, default=>1, usage=>"Create a page for each image"); add_option(2,'dir_thumbs',$OPTION_BOOL, default=>1, usage=>"Directories have thumbnail (if supported by theme)"); +add_option(2,'dir_thumb',$OPTION_STR, usage=>"Override using captions to choose dir_thumbs"); add_option(1,'medium', $OPTION_STR, args=>'', usage=>"Generate medium size images"); add_option(2,'just_medium',$OPTION_BOOL, usage=>"Don't link to full-size images"); add_option(1,'embed',$OPTION_BOOL, default=>1, usage=>"Use image pages for non-picture image pages"); @@ -3747,6 +3748,17 @@ my $dir = $data->{paths}{dir}; my $child_path = "$dir/$child"; + my ($pushed,$conf) = (0,"$child_path/$opt->{conf_file}"); + my $child_dir_thumb_override = 0; + if (-r $conf) { + push_opts($opt); + $pushed = 1; + $opt->{q} = 1; # don't want to get the "Read conf:" message early + read_conf($opt,undef,$conf,0); + $child_dir_thumb_override = $opt->{dir_thumb}; + pop_opts($opt); + } + # Basic method, choose first picture by captions.txt # This is redundant work, we'll probably do this again when # we traverse the child - can we cache this somewhere?? @@ -3754,15 +3766,40 @@ gather_contents($opt,$child_data); $data->{obj}{$child}{num_dirs} = @{$child_data->{dirs}} if $child_data->{dirs}; - return undef unless $child_data->{pics}; - get_captions($opt,$child_data); # For sorting - sort_info($opt,$child_data); - my @images = grep is_image($opt,$_), @{$child_data->{pics}}; - - $data->{obj}{$child}{num_pics} = scalar @images; - - return undef unless @images; - ($child_path,$child,"$child_path/$images[0]",$images[0]); + my @search = (); + my $override_into_dir; + if (-d "$child/$child_dir_thumb_override") { + push @search, "$child_dir_thumb_override"; + $override_into_dir = $child_dir_thumb_override; + undef $child_dir_thumb_override; + } elsif (defined @{$child_data->{dirs}}) { + @search = @{$child_data->{dirs}}; + } + if (!($child_data->{pics} || $child_dir_thumb_override)) { + foreach my $search_child ( @search ) { + my ($a,$url,$full_path,$d) = dir_image($opt,$child_data,$search_child); + if ($full_path) { + $url = "$child/$url"; + return ($a,$url,$full_path,$d); + } + } + return undef; + } + + my $image_name; + if ($child_dir_thumb_override) { + $image_name = $child_dir_thumb_override; + } else { + get_captions($opt,$child_data); # For sorting + sort_info($opt,$child_data); + my @images = grep is_image($opt,$_), @{$child_data->{pics}}; + + $data->{obj}{$child}{num_pics} = scalar @images; + + return undef unless @images; + $image_name = $images[0]; + } + ($child_path,$child,"$child_path/$image_name",$image_name); } sub handle_child { @@ -3785,7 +3822,10 @@ get_size($opt,'thumb',$obj); # URL to find the thumbnail - $obj->{URL}{album_page}{thumb} = quote("$url/$opt->{dir}/$obj->{thumb}{file}",$opt,1); + use File::Basename; + my $tn_target_name = $obj->{thumb}{file}; + my $tn_fullpath = "$url/$opt->{dir}/$tn_target_name"; + $obj->{URL}{album_page}{thumb} = quote("$tn_fullpath",$opt,1); } # Should caption be done here? From album-author@d... Sat Jun 11 18:28:02 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] [PATCH] recurse to find directory thumbs In-Reply-To: <1118175044.28460.31.camel@localhost> References: <1118175044.28460.31.camel@localhost> Message-ID: > The appended patch calls dir_image() recursively if the current > directory has no pictures of its own, but does have children. This is great - thanks for sending it in. I'll look into putting this into 3.10 when it's released. I was originally going to leave all the grunt work of picking dir_thumbs to plugins, but this is a fairly simple and useful solution. As far as 3.10 goes, it kills me that I haven't been able to release it yet. The code is basically done, and the docs are even written, but I just need to do a few final touches and some testing, and I've had some financial setbacks the last few months that have pushed me back towards doing paying work all the time. I'm on vacation in about four weeks, and I plan on doing a big release then. If anyone wants to test 3.10 (especially if you're interested in learning how to write plugins), feel free to contact me. And again, thanks for the patch! Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From dave@s... Mon Jun 13 07:06:02 2005 From: dave@s... (Dave Hansen) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] [PATCH] recurse to find directory thumbs In-Reply-To: References: <1118175044.28460.31.camel@localhost> Message-ID: <1118671562.6780.65.camel@localhost> On Sat, 2005-06-11 at 18:28 -0700, David Ljung Madison wrote: > > The appended patch calls dir_image() recursively if the current > > directory has no pictures of its own, but does have children. > > This is great - thanks for sending it in. > > I'll look into putting this into 3.10 when it's released. I was > originally going to leave all the grunt work of picking dir_thumbs > to plugins, but this is a fairly simple and useful solution. One little issue I ran into with my patch. When building the new conf file name, it used this: my ($pushed,$conf) = (0,"$child_path/$opt->{conf_file}"); That's fine, but it adds a '/' to the path name. Because of this, it re-reads the conf file a bunch of times and recurses really, really far. It stops miraculously, but I'm not quite sure why. To fix it, I just removed the '/': my ($pushed,$conf) = (0,"$child_path$opt->{conf_file}"); Although it might also be a good idea to have this line in read_conf: $conf_str =~ s|^\Q$opt->{topdir}\E/?||; Also strip out any consecutive slashes (maybe with a warning). Would probably be a safer long-term solution. -- Dave From dave@s... Mon Jun 13 07:06:02 2005 From: dave@s... (Dave Hansen) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] [PATCH] recurse to find directory thumbs In-Reply-To: References: <1118175044.28460.31.camel@localhost> Message-ID: <1118671562.6780.65.camel@localhost> On Sat, 2005-06-11 at 18:28 -0700, David Ljung Madison wrote: > > The appended patch calls dir_image() recursively if the current > > directory has no pictures of its own, but does have children. > > This is great - thanks for sending it in. > > I'll look into putting this into 3.10 when it's released. I was > originally going to leave all the grunt work of picking dir_thumbs > to plugins, but this is a fairly simple and useful solution. One little issue I ran into with my patch. When building the new conf file name, it used this: my ($pushed,$conf) = (0,"$child_path/$opt->{conf_file}"); That's fine, but it adds a '/' to the path name. Because of this, it re-reads the conf file a bunch of times and recurses really, really far. It stops miraculously, but I'm not quite sure why. To fix it, I just removed the '/': my ($pushed,$conf) = (0,"$child_path$opt->{conf_file}"); Although it might also be a good idea to have this line in read_conf: $conf_str =~ s|^\Q$opt->{topdir}\E/?||; Also strip out any consecutive slashes (maybe with a warning). Would probably be a safer long-term solution. -- Dave From dave@s... Tue Aug 2 18:11:59 2005 From: dave@s... (Dave Hansen) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] get_xy() for each file Message-ID: <1123031519.17231.194.camel@localhost> While not a horribly huge deal, I noticed that all of the calls to get_size()->get_xy() which tend to run jhead/identify/convert really slow down the execution of album. They're responsible for a very large amount of the total CPU used. Just conceptually, it doesn't seem necessary to be checking the image sizes each time, especially if the modification time for the file is earlier than the thumbnails. Has anyone given some thought to optimizing this? I just briefly tried, but there seems to be an assumpion or two that, if an image doesn't have its {x} property set, then it isn't a valid image. See 'sub Image' for an example. So, two questions: would anyone like patches that use something a bit more efficient than forking a helper? Surely the optional use of one of the jpeg perl libraries would be faster than forking and exec'ing a helper for each file. Or, can we have an optimized path to skip the get_xy() when all of the modification times line up? Just doing the stat()s to get mtime should be pretty cheap. For instance, doing stat() on 44k files only takes 0.21 seconds on my 1GHz PIII when the caches are warm: dave@blackbird:~/pictures$ time find -type f | wc 44634 44634 2625544 real 0m0.219s user 0m0.119s sys 0m0.179s -- Dave From album-author@d... Wed Aug 3 05:29:23 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] get_xy() for each file In-Reply-To: <1123031519.17231.194.camel@localhost> References: <1123031519.17231.194.camel@localhost> Message-ID: > amount of the total CPU used. Just conceptually, it doesn't seem > necessary to be checking the image sizes each time, especially if the > modification time for the file is earlier than the thumbnails. Sometimes we need the info even if the images haven't changed. For example, if we aren't using medium images, and the theme changes, then we need to know the size of the images. I considered writing the code so that we only calculated the XY when necessary, that's more similar to how the original album worked, but it turns out that: 1) The code is *much* cleaner this way, and this is a big part of the reason album 3.0 has so many more capabilities that v2.* (And far more room for growth) 2) Because of plugins, we don't actually know whether we need an images info or not. I've also considered keeping a database of image information with each directory - but that's another file and set of information to maintain, and it goes somewhat against the concept of album being a small footprint. Maybe someday. It wouldn't be too hard, actually, to make a plugin that replaces the get_xy call with something that caches the info in a database, I'll leave that as an exercize to someone else, I don't have time right now. (And this will be with v3.10, which I plan to release when I get back from Spain fter the 8th) I finally decided that all the work I was doing too speed up album wasn't really worth it, considering how fast computers are these days. In particular, please consider using '-add' instead of rerunning album on your entire photo tree. In the end, I think album is fairly good at avoiding doing unnecessary work, considering how complicated the task actually gets, but thanks to '-add' it shouldn't really matter. > the jpeg perl libraries would be faster than forking and exec'ing a > helper for each file. That's not clear to me at all - I haven't done tests, but I think it's safe to assume that imagemagick is significantly faster at processing images than perl. Again, it would be easy to write a plugin that replaces the get_xy call with something that uses the jpeg libraries, I have an example of that for getting exif info using perl instead of jhead. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From steveo@s... Wed Aug 3 05:53:34 2005 From: steveo@s... (Steven W. Orr) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] get_xy() for each file In-Reply-To: References: <1123031519.17231.194.camel@localhost> Message-ID: On Wednesday, Aug 3rd 2005 at 05:29 -0700, quoth David Ljung Madison: =>> amount of the total CPU used. Just conceptually, it doesn't seem =>> necessary to be checking the image sizes each time, especially if the =>> modification time for the file is earlier than the thumbnails. => =>Sometimes we need the info even if the images haven't changed. For example, =>if we aren't using medium images, and the theme changes, then we need to know =>the size of the images. => =>I considered writing the code so that we only calculated the XY =>when necessary, that's more similar to how the original album worked, but =>it turns out that: => =>1) The code is *much* cleaner this way, and this is a big part of the => reason album 3.0 has so many more capabilities that v2.* => (And far more room for growth) =>2) Because of plugins, we don't actually know whether we need => an images info or not. => =>I've also considered keeping a database of image information =>with each directory - but that's another file and set of information =>to maintain, and it goes somewhat against the concept of album =>being a small footprint. Maybe someday. I understand what you're saying about small footprint, but frankly I have a different perspective. http://steveo.syslang.net/album If I add a picture to my album and rerun on my system with a gig of ram and a pair of Athlon 1600's it takes about 15 minutes. If the whole thing were to be rerun from scratch with all the thumbs getting recreated it's close to 25 minutes. I wouldn't mind seeing a speedup. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net From dave@s... Wed Aug 3 11:38:56 2005 From: dave@s... (Dave Hansen) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] get_xy() for each file In-Reply-To: References: <1123031519.17231.194.camel@localhost> Message-ID: <1123094336.22343.14.camel@localhost> On Wed, 2005-08-03 at 05:29 -0700, David Ljung Madison wrote: > > amount of the total CPU used. Just conceptually, it doesn't seem > > necessary to be checking the image sizes each time, especially if the > > modification time for the file is earlier than the thumbnails. > > Sometimes we need the info even if the images haven't changed. For example, > if we aren't using medium images, and the theme changes, then we need to know > the size of the images. > > I considered writing the code so that we only calculated the XY > when necessary, that's more similar to how the original album worked, but > it turns out that: > > 1) The code is *much* cleaner this way, and this is a big part of the > reason album 3.0 has so many more capabilities that v2.* > (And far more room for growth) > 2) Because of plugins, we don't actually know whether we need > an images info or not. Perhaps hiding the x/y behind a function call instead of having it just be a field that can be accessed would speed this up. That way, the core album can keep from doing the calculations, except when that function is actually called into. > I've also considered keeping a database of image information > with each directory - but that's another file and set of information > to maintain, and it goes somewhat against the concept of album > being a small footprint. Maybe someday. > > It wouldn't be too hard, actually, to make a plugin that replaces > the get_xy call with something that caches the info in a database, > I'll leave that as an exercize to someone else, I don't have > time right now. (And this will be with v3.10, which I plan to > release when I get back from Spain fter the 8th) Linus Torvalds' git has given me a few ideas about stuff like this. We really don't need a database on *top* of the filesystem. If we even created a file called .$qimg.size=123x456, it would speed up the operations, and keep us from having to use a DB. Plus, with Linux having such a fast set caches, the lookups can be really quick. > I finally decided that all the work I was doing too speed up > album wasn't really worth it, considering how fast computers > are these days. In particular, please consider using '-add' > instead of rerunning album on your entire photo tree. My problem tends to be when I move images around. I forget what I moved, and where, and I just re-run album over the whole thing. I could be more careful, but I like to be lazy. > > the jpeg perl libraries would be faster than forking and exec'ing a > > helper for each file. > > That's not clear to me at all - I haven't done tests, but I > think it's safe to assume that imagemagick is significantly > faster at processing images than perl. This is running album on a directory with 497 images. Current time album, using jhead with warm caches: real 0m2.503s real 0m2.502s real 0m2.507s real 0m2.503s real 0m2.542s Then, I added this to the beginning of get_xy(): use Image::Size qw(:all); my ($width, $height, $err) = imgsize($qimg); return ($width, $height); Same directory: real 0m1.769s real 0m1.749s real 0m1.752s real 0m1.755s real 0m1.759s > Again, it would be easy to write a plugin that replaces the > get_xy call with something that uses the jpeg libraries, I > have an example of that for getting exif info using perl > instead of jhead. That'd be nice. I eagerly awat 3.1 :) -- Dave From fred@d... Fri Aug 5 15:41:30 2005 From: fred@d... (Fred Clausen) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Bug with generating avi thumbnails. Message-ID: <20050805224130.GA27558@srv> Hi all, I have some movies ending in 'bla.AVI'. When I run album on a dir containing these files, I get the following error: [album] Can't get [/path/to/file/movie.AVI]] size from 'convert -verbose' output But if it is renamed to 'movie.avi', then it all works well. So it seems that album does not recognise *.AVI as a movie but an image. Cheers, Fred. From album-author@d... Mon Aug 8 16:01:05 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Bug with generating avi thumbnails. In-Reply-To: <20050805224130.GA27558@srv> References: <20050805224130.GA27558@srv> Message-ID: > I have some movies ending in 'bla.AVI'. When I run album on a dir > containing these files, I get the following error: > > [album] Can't get [/path/to/file/movie.AVI]] size from 'convert > -verbose' output Version of album? Please always be sure to upgrade before submitting bug reports. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From album-author@d... Tue Aug 9 06:11:30 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] get_xy() for each file In-Reply-To: References: Message-ID: > Perhaps hiding the x/y behind a function call instead of having it just > be a field that can be accessed would speed this up. That way, the core I don't quite understand - there is a function call, and then the values are stored in the image information fields. > Linus Torvalds' git has given me a few ideas about stuff like this. We > really don't need a database on *top* of the filesystem. If we even > created a file called .$qimg.size=123x456, it would speed up the True, but it would be messy, and would leave lots of files around... > My problem tends to be when I move images around. I forget what I > moved, and where, and I just re-run album over the whole thing. I could > be more careful, but I like to be lazy. Then you will love the 'mv' plugin that I have for album 3.10, it moves images, captions and thumbnails and reruns album on the appropriate directory. > Current time album, using jhead with warm caches: > real 0m2.503s > > Same directory: (with Image::Size) > real 0m1.769s Consider me shocked.. I'll make it a plugin. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From dave@s... Tue Aug 9 10:21:39 2005 From: dave@s... (Dave Hansen) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] get_xy() for each file In-Reply-To: References: Message-ID: <1123608100.10337.72.camel@localhost> On Tue, 2005-08-09 at 06:11 -0700, David Ljung Madison wrote: > > Perhaps hiding the x/y behind a function call instead of having it just > > be a field that can be accessed would speed this up. That way, the core > > I don't quite understand - there is a function call, and then the values > are stored in the image information fields. I just meant that, any users outside of the core album should not use the $image->{x/y} method to access the image size. Instead they should only use a function like get_xy(). That way, $image->{x/y} becomes only a cache, and the core album doesn't have to worry about if any plugins need image sizes. -- Dave From shirman@k... Fri Aug 26 14:18:08 2005 From: shirman@k... (Yuri Shirman) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] creating slideshow? Message-ID: <1125091088.26665.1.camel@korablik> Hi, Is there a theme (or a way to create new/modify existing theme) so that one could view a given album in a slideshow mode? Thanks, Yuri Shirman -- Yuri Shirman From vag@p... Sun Aug 28 00:33:26 2005 From: vag@p... (Vladimir A. Gurevich) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Creating album views Message-ID: <431168C6.8020301@paulidav.org> Hello, I've just found the album script! Thanks a lot for the great piece of software. Here is my question: I'd like to be able to maintain a "master" album that has all the pictures (from, say, my summer vacation) and then be able to create a "view", i.e. an album containing only pictures I made during a specific day or, say, containing only pictures of my son, etc. Essentially, I'd like to be able to create these views by just specifying which pictures belong to them and that's it. It would be definitely nice if captions will also be "inherited". Is it possible to do without creating many copies around? I tried to create a new directory and then symlink the chosen pictures there, but it looks like album (and tkalbum) ignores them. Also, it's not a nice solution since captions are not inherited and I'd be also required to symlink the thumbs. Is there a better way? Thanks, Vladimir From atopo@o... Mon Sep 19 13:13:39 2005 From: atopo@o... (Alexander Topolanek) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Problems with album on a sparc64 and OpenBSD 3.6 Message-ID: <01f201c5bd56$9fe613e0$2e00a8c0@shuttle> Hi, I was trying album on OpenBSD 3.6 on a Sparc64, but it fails with "Can't get [path/filename] size from 'convert -verbose' output" Album Version is v3.07, Imagemagick is 6.1.9 02/10/05 Q16. Any Ideas how I can dig deeper into that problem? How is calling album the convert, can I get some more information from album what it's issuing and what convert is telling back? thanks Alexander From album-author@d... Mon Sep 19 17:48:35 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Re: Problems with album on a sparc64 and OpenBSD 3.6 In-Reply-To: <01f201c5bd56$9fe613e0$2e00a8c0@shuttle> References: <01f201c5bd56$9fe613e0$2e00a8c0@shuttle> Message-ID: > How is calling album the convert, can I get some more information > from album what it's issuing and what convert is telling back? As in: http://MarginalHacks.com/Hacks/album/Docs/Section_6.html#Bug_reports % album -d Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From roland@s... Sun Nov 13 06:00:34 2005 From: roland@s... (Roland Rosenfeld) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] exif tags added twice Message-ID: <20051113140034.GY1707@besan.sail.spinnaker.de> Hi! I'm just playing around with the exif_image option in my album.conf file. I added these lines to album.conf: save_conf 0 exif_image "
Kamera: %Camera model%" exif_image "
Blende: %Aperture%" exif_image "
Verschlusszeit: %Exposure time%" exif_image "
Brennweite: %Focal length%" exif_image "
Blitz: %Flash used%" ~/.album.conf exists but is empty. In my subdirectories are no other album.conf files. If I run album --force_html subdir the exif tags are added once to the captions in subdir. But if there is a subdir/subsubdir, they are added twice to the images in subsubdir. If I run album --force_html without giving a subdirectory, the above exif lines are added twice to all images. I have no idea, where the second instance comes from. As I wrote above, there does not exist any other album.conf file, where album could take the second instance from and after running album, the exif_image commands aren't added to album.conf or ~/.album.conf (correct, because I requested this with "save_conf 0"). But why are they still duplicated? Is there a way to get rid of this duplication? I wasn't able to add clear_exif_image or no_exif_image to album.conf, they seem only to exist on command line, but I don't want to enter the exif_image options on command line every time I call album. BTW: I'm currently trying album 3.10, don't know whether this problem was existing in older versions, too. Tschoeeee Roland From album-author@d... Sun Nov 13 13:44:30 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Re: exif tags added twice In-Reply-To: <20051113140034.GY1707@besan.sail.spinnaker.de> References: <20051113140034.GY1707@besan.sail.spinnaker.de> Message-ID: > save_conf 0 I wouldn't use 'save_conf' in your album.conf files, except for very specific testing circumstances. Also, for submitting bug reports/questions, please follow: http://MarginalHacks.com/Hacks/album/Docs/Section_5.html#Bug_reports Specifically: - Get the most current themes - Send me the output of -d You can also send bug reports directly to me - about 90% of bug reports end up being non-album bugs. The other 10% can go on the list if I can't fix them immediately. > I wasn't able to add clear_exif_image or no_exif_image to album.conf.. That is true - those are not album.conf lines, they are for changing your album.conf. Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From scottbertin@y... Sat Nov 26 13:43:24 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:33 2006 Subject: [Album] Some nuances of plugins with multiple subdirectories Message-ID: <4388D6FC.40706@yahoo.com> The following behavior was not immediately apparent to me when I started writing and using plugins. I thought I'd share it with others to avoid any confusion. When running "album -plugin plugin A", all the hooks are called. Running "album A" after that will load the plugin (It was stored in A/album.conf), but will not call the pre_do_albums hook. This makes sense because A/album.conf is not read until after pre_do_albums is called. If A is a subdirectory of B, running "album B" will cause the plugin to be loaded, but the pre_do_albums, do_album_top, and end_album_top will not be called. Again, this makes sense if you think about when the album.conf file is loaded. If you are writing a plugin, I would suggest avoiding the pre_do_albums, do_album_top, and end_album_top hooks. If you must use them, warn your users that there could be problems unless the plugin is loaded at a specific point. If B/C/album.conf that also loads plugin, start_plugin will be called twice when "album B" is run. Once for directory A, and once for C. Any package level variables will retain their values from running the first directory. If B/A/D/album.conf loads album.conf, start_plugin will not be called for directory D, because it is already loaded from directory A. Fortunately, if B/E/album.conf does not load plugin, it will not be used for directory E. I've included a small plugin below that can be used to test these behaviors. Scott J. Bertin scottbertin@yahoo.com -- begin plugin -- use strict; my $count=0; sub start_plugin { my ($opt) = @_; # Setup the hooks album::hook($opt, 'pre_do_albums', \&print_hook); album::hook($opt, 'do_album_top', \&print_album_hook); album::hook($opt, 'end_album_top', \&print_album_hook); album::hook($opt, 'do_album', \&print_album_hook); album::hook($opt, 'end_album', \&print_album_hook); $count++; print STDERR "start_plugin called $count times\n"; return { author => 'Scott J. Bertin', href => 'mailto://scottbertin@yahoo.com', version => '1.0', description => 'Test plugin behavior', }; } sub print_hook { my ($opt, $hookname) = @_; print STDERR "$hookname called\n"; return undef; } sub print_album_hook { my ($opt, $data, $hookname) = @_; print STDERR "$hookname called for $data->{paths}{dir}\n"; return undef; } # Plugins always end with: 1; From scottbertin@y... Tue Nov 22 17:59:45 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PATCH] Fix the name for the stop_hashes hook Message-ID: <4383CD11.6090408@yahoo.com> The following patch fixes the name for the stop_hashes hook in album 3.10. Scott J. Bertin scottbertin@yahoo.com Index: album =================================================================== RCS file: /Users/scottbertin/.cvsroot/album/album,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 album --- album 18 Nov 2005 14:34:27 -0000 1.1.1.1 +++ album 18 Nov 2005 14:35:02 -0000 @@ -2135,7 +2136,7 @@ sub stop_hashes { my ($opt) = @_; - my $val = do_hook($opt,undef, 'show_hashes'); + my $val = do_hook($opt,undef, 'stop_hashes'); # Description: Finish the progress meter # Description: (You should hook all or none of the *_hashes hooks.) # Returns: 1 if you don't want normal hashes printed From scottbertin@y... Tue Nov 22 18:00:45 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PATCH] -burn doesn't imply -index index.html everywhere Message-ID: <4383CD4D.5070802@yahoo.com> Album 3.10 doesn't use index.html for the back and parent albums in themes when -burn is used. The following patch fixes it. Scott J. Bertin scottbertin@yahoo.com Index: album =================================================================== RCS file: /Users/scottbertin/.cvsroot/album/album,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 album --- album 18 Nov 2005 14:34:27 -0000 1.1.1.1 +++ album 18 Nov 2005 14:35:02 -0000 @@ -3382,7 +3386,9 @@ my \$dotdots = num('parent_albums') - \$num - 1; \$dotdots++ if Image_Page(); my \$str = ""; - \$str .= "" if \$dotdots; + my \$index = Option('index'); + \$index = \$index || Option('default_index') if Option('burn'); + \$str .= "" if \$dotdots; \$str .= Pretty(\$parent_albums->[\$num],1); \$str .= "" if \$dotdots; \$str; @@ -3398,8 +3404,10 @@ # Go back to a previous index, or just ".." for the top page of the album sub Back { + my \$index = Option('index'); + \$index = \$index || Option('default_index') if Option('burn'); (num('parent_albums')>1 || Image_Page()) ? - "'../".Option('index')."'" : "'".Option('top')."'"; + "'../".\$index."'" : "'".Option('top')."'"; } ######################### From scottbertin@y... Tue Nov 22 18:00:12 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PATCH] Medium and thumbnail hooks Message-ID: <4383CD2C.1060204@yahoo.com> The following patch fixes how album 3.10 handles the value returned by the medium and thumbnail hooks. It was overwriting it instead of using it. Scott J. Bertin scottbertin@yahoo.com Index: album =================================================================== RCS file: /Users/scottbertin/.cvsroot/album/album,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 album --- album 18 Nov 2005 14:34:27 -0000 1.1.1.1 +++ album 18 Nov 2005 14:35:02 -0000 @@ -5223,8 +5235,8 @@ # Description: so check in your hook for the types you can read. # Returns: Full path to medium image if ($obj->{medium}{path}) { - $obj->{medium}{path} = $obj->{medium}{file}; - $obj->{medium}{path} =~ s|.*$opt->{slash}||g; + $obj->{medium}{file} = $obj->{medium}{path}; + $obj->{medium}{file} =~ s|.*$opt->{slash}||g; return get_size($opt,'medium',$obj) } @@ -5285,8 +5297,8 @@ # Description: so check in your hook for the types you can read. # Returns: Full path to the thumbnail if ($obj->{thumb}{path}) { - $obj->{thumb}{path} = $obj->{thumb}{file}; - $obj->{thumb}{path} =~ s|.*$opt->{slash}||g; + $obj->{thumb}{file} = $obj->{thumb}{path}; + $obj->{thumb}{file} =~ s|.*$opt->{slash}||g; return get_size($opt,'thumb',$obj); } From scottbertin@y... Tue Nov 22 19:36:59 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PLUGIN] specified_sort.alp - a plugin to change the sort order Message-ID: <4383E3DB.9090600@yahoo.com> This plugin allows sorting of pics/dirs as specified in a file (album.order by default). The file is a simple list of names in the order they should be sorted. Unknown names are sorted in the default order. The following special names are recognized: [:NOREVERSE:] Ignores the reverse_sort option for the current file. [:UNKNOWN:] Placeholder for unknown values, overrides the unknowns_first option. [:DIRSONLY:] Only sort directories, not pics. [:PICSONLY:] Only sort pics, not directories. If both [:DIRSONLY:] and [:PICSONLY:] both appear in the file, no sorting is done. The file is only checked for exact matches, patterns are not used. This is intentional so that the order is unambiguous. If an item appears twice in the file, the order of that item will depend on the first occurrence that is found when the search is made. This creates interesting possibilities for ordering with and without the reverse_sort option. If you put an item both first and last in the file, it will appear first regardless of the reverse_sort option, assuming no unknowns, or an [:UNKNOWNS:] line between the 2 occurrences. Scott J. Bertin scottbertin@yahoo.com -------------- next part -------------- # Album Plugin: captions/formatting/specified_sort # For info: 'album -plugin_info captions/formatting/specified_sort' # For usage: 'album -plugin_usage captions/formatting/specified_sort' use strict; my $LICENSE = << 'LICENSE'; Copyright (c) 2005 Scott J. Bertin Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. LICENSE my $DESCRIPTION = << 'DESCRIPTION'; Sort pics/dirs as specified in a file. The file is a simple list of names in the order they should be sorted. Unknown names are sorted in the default order. The following special names are recognized: [:NOREVERSE:] Ignores the reverse_sort option for the current file. [:UNKNOWN:] Placeholder for unknown values, overrides the unknowns_first option. [:DIRSONLY:] Only sort directories, not pics. [:PICSONLY:] Only sort pics, not directories. If both [:DIRSONLY:] and [:PICSONLY:] both appear in the file, no sorting is done. The file is only checked for exact matches, patterns are not used. This is intentional so that the order is unambiguous. If an item appears twice in the file, the order of that item will depend on the first occurence that is found when the search is made. This creates interesting possibilities for ordering with and without the reverse_sort option. If you put an item both first and last in the file, it will appear first regardless of the reverse_sort option, assuming no unknowns, or an [:UNKNOWNS:] line between the 2 occurrences. DESCRIPTION sub start_plugin { my ($opt) = @_; # Setup the options album::add_option(1, 'show_license', album::OPTION_BOOL, one_time=>1, usage=>'Show the license for this plugin.'); album::add_option(1, 'what_to_sort', album::OPTION_STR, default=>'both', usage=>'What to sort (pics, dirs, both)'); album::add_option(1, 'ignore_reverse', album::OPTION_BOOL, usage=>'Ignore the reverse_sort option'); album::add_option(1, 'unknowns_first', album::OPTION_BOOL, usage=>'Sort unknown pics/dirs first? (default is last)'); album::add_option(2, 'filename', album::OPTION_STR, default=>'album.order', usage=>'Name of the file containing the sort order.'); # Setup the hooks album::hook($opt, 'sort_dirs', \&do_sort); album::hook($opt, 'sort_pics', \&do_sort); return { author => 'Scott J. Bertin', href => 'mailto://scottbertin@yahoo.com', version => '1.0', description => $DESCRIPTION, }; } sub find_index { my ($element,$array) = @_; return undef unless $array; for(my $i=0; $i $b_before; } else { return -1; } } elsif (defined $b_before) { return 1; } my $a_after = find_index($a, $after); my $b_after = find_index($b, $after); if (defined $a_after) { if (defined $b_after) { return $a_after <=> $b_after; } else { return 1; } } elsif (defined $b_after) { return -1; } return album::sort_order($opt, $data, $a, $b); } sub read_file { my ($f) = @_; return undef unless $f; return undef unless (-r $f); return undef unless (open(FILE,"<$f")); my @contents; while() { # Strip leading and trailing whitespace s/^\s+//; s/\s+$//; # Skip blank lines push(@contents,$_) unless length($_) == 0; } close FILE; return @contents; } sub do_sort { my ($opt, $data, $hookname, @list) = @_; show_license($opt) if album::option($opt, 'show_license'); my $sort_type = lc album::option($opt, 'what_to_sort'); album::usage("Unknown $opt->{_curr_plugin}:what_to_sort option: $sort_type\n". "\tShould be pics, dirs, or both.") unless grep($sort_type eq $_, qw(pics dirs both)); return undef if $hookname eq 'sort_dirs' && $sort_type eq 'pics'; return undef if $hookname eq 'sort_pics' && $sort_type eq 'dirs'; # Get the order for this album my $dir = $data->{paths}{dir}; my $filename = album::option($opt, 'filename'); my $slash = album::option($opt, 'slash'); my @order = read_file($dir.$slash.$filename); return undef unless defined $order[0]; # Check for limitations on what to sort my $dirsonly = find_index('[:DIRSONLY:]', \@order); my $picsonly = find_index('[:PICSONLY:]', \@order); return undef if $hookname eq 'sort_dirs' && defined $picsonly; return undef if $hookname eq 'sort_pics' && defined $dirsonly; # Remove [:DIRSONLY:] and [:PICSONLY:] from the order if(defined $dirsonly) { splice(@order, $dirsonly, 1); } elsif(defined $picsonly) { splice(@order, $picsonly, 1); } # Should the reverse flag be ignored for the specified order my $reverse = $opt->{reverse_sort}; my $noreverse = find_index('[:NOREVERSE:]', \@order); if(defined $noreverse) { # Remove [:NOREVERSE:] splice(@order, $noreverse, 1); } elsif ($reverse && !album::option($opt, 'ignore_reverse')) { @order = reverse @order; } # Split the order into parts before and after unknown elements my $unknown = find_index('[:UNKNOWN:]', \@order); my $before; my $after; if(defined $unknown) { if($unknown > 0) { $before = [@order[0..$unknown-1]]; } if($unknown < $#order) { $after = [@order[$unknown+1..$#order]]; } } else { if($reverse xor album::option($opt, 'unknowns_first')) { $after = \@order; } else { $before = \@order; } } return sort { sort_order($opt, $data, $before, $after, $a, $b) } @list; } sub show_license { my ($opt) = @_; print "The following license applies ONLY to the ", $opt->{_curr_plugin}, " plugin, and should not be construed ", "to apply to album, or any other plugin.\n\n", $LICENSE; exit; } # Plugins always end with: 1; From scottbertin@y... Tue Nov 22 18:01:35 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PATCH] Use the full path to find files instead of assuming where they are Message-ID: <4383CD7F.107@yahoo.com> The following patch to album 3.10 uses the full path to find files in case a plugin puts them in an unexpected place. I have a plugin that allows all of the image files to be someplace other than the location normally used by album. I'll send it to the list soon, I just need to document it first. Scott J. Bertin scottbertin@yahoo.com Index: album =================================================================== RCS file: /Users/scottbertin/.cvsroot/album/album,v retrieving revision 1.4 diff -u -r1.4 album --- album 18 Nov 2005 14:51:42 -0000 1.4 +++ album 18 Nov 2005 18:05:54 -0000 @@ -4548,11 +4548,11 @@ # Paths my $dir = $data->{paths}{dir}; - my $path = "$dir/$pic"; my $obj = $data->{obj}{$pic}; + my $path = $obj->{full}{path}; # Figure out type - $obj->{is_movie} = is_movie($opt,$pic); + $obj->{is_movie} = is_movie($opt,$path); my $can_embed = $obj->{is_movie}; $can_embed = 1 if $pic =~ /\.(pdf|ps)$/i; my $tag = 'img'; @@ -4625,12 +4625,15 @@ # -no_embed USED to mean that movie pages didn't have image pages.. #$use_image_pages = 0 if $obj->{is_movie} && !$opt->{embed}; + my $image_dir = "$opt->{dir}/" if $opt->{dir}; + my $image_path = "$dir/$image_dir"; if ($use_image_pages) { my $image_page = "$pic$data->{paths}{page_post_url}"; - $obj->{URL}{album_page}{image} = url_quote($opt, "$opt->{dir}/$image_page"); + $obj->{URL}{album_page}{image} = url_quote($opt, "$image_dir$image_page"); # Kludge - the number of ".." should be equal to the pathsize of $opt->{dir} my $image = ($opt->{just_medium} && $obj->{thumb}) - ? $obj->{medium}{file} : "../$pic"; + ? $obj->{medium}{path} : $obj->{full}{path}; + $image = diff_path($opt, $image_path, $image); $obj->{URL}{image_page}{image} = url_quote($opt, $image); $obj->{URL}{image_page}{image_page} = url_quote($opt, $image_page); @@ -4638,28 +4641,35 @@ # -embed: pic or medium, but pic if movie (../$pic) # -noembed and -medium: medium # -noembed and -nomedium: snapshot - my $image_src = $obj->{medium}{file} || "../$pic"; + my $image_src = $obj->{medium}{path} || $obj->{full}{path}; if ($obj->{snapshot}{file}) { - $image_src = $opt->{embed} ? "../$pic" : - ($obj->{medium}{file} || $obj->{snapshot}{file}); + $image_src = $opt->{embed} ? $obj->{full}{path} : + ($obj->{medium}{path} || $obj->{snapshot}{path}); } + $image_src = diff_path($opt, $image_path, $image_src); $obj->{URL}{image_page}{image_src} = url_quote($opt, $image_src); # Thumbnail - $obj->{URL}{album_page}{thumb} = url_quote($opt, "$opt->{dir}/$obj->{thumb}{file}"); - $obj->{URL}{image_page}{thumb} = url_quote($opt, $obj->{thumb}{file}); + $obj->{URL}{album_page}{thumb} = + url_quote($opt, diff_path($opt, $dir, $obj->{thumb}{path})); + $obj->{URL}{image_page}{thumb} = + url_quote($opt, diff_path($opt, $image_path, $obj->{thumb}{path})); } else { - $obj->{URL}{album_page}{image} = url_quote($opt, $pic); - $obj->{URL}{album_page}{thumb} = url_quote($opt, "$opt->{dir}/$obj->{thumb}{file}"); + $obj->{URL}{album_page}{image} = + url_quote($opt, diff_path($opt, $dir, $obj->{full}{path})); + $obj->{URL}{album_page}{thumb} = + url_quote($opt, diff_path($opt, $dir, $obj->{thumb}{path})); # We might normally have image pages, just not for this non-image - $obj->{URL}{image_page}{image_page} = url_quote($opt, "../$pic") + $obj->{URL}{image_page}{image_page} = + url_quote($opt, diff_path($opt, $image_path, $obj->{full}{path})) if $opt->{image_pages}; } # -transform_url if ($opt->{transform_url}) { $obj->{URL}{album_page}{image} = $opt->{transform_url}; - $obj->{URL}{album_page}{image} =~ s/%S/$pic/g; + my $pic_path = diff_path($opt, $dir, $obj->{full}{path}); + $obj->{URL}{album_page}{image} =~ s/%S/$pic_path/g; my $s = $pic; $s =~ s/\.[^\.]+$//; $obj->{URL}{album_page}{image} =~ s/%s/$s/g; } From scottbertin@y... Thu Nov 24 05:14:37 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PLUGIN] epeg.alp - use epeg to scale JPEG images. Message-ID: <4385BCBD.5010208@yahoo.com> Attached is a plugin for album 3.10 to use epeg to scale JPEG (and only JPEG) images. It is dramatically faster than using convert. The time to process my entire photo collection dropped from approximately 3 hours to just over an hour. It now takes significantly more time to generate the indexes than the images. This plugin requires epeg, which can be found at http://enlightenment.freedesktop.org/. Additionally, it will use Image::Epeg (from CPAN) if it is available. Scott J. Bertin scottbertin@yahoo.com -------------- next part -------------- # Album Plugin: utils/epeg # For info: 'album -plugin_info utils/epeg' # For usage: 'album -plugin_usage utils/epeg' # For license: 'album -utils/epeg:show_license' # # epeg can be found at http://enlightenment.freedesktop.org/ use strict; use File::Copy; my $LICENSE = << 'LICENSE'; Copyright (c) 2005 Scott J. Bertin Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. LICENSE my $DESCRIPTION = << 'DESCRIPTION'; Use epeg to scale JPEG images. DESCRIPTION my $IMAGE_EPEG = album::attempt_require('Image::Epeg'); my $EPEG_COMMAND; sub start_plugin { my ($opt) = @_; # Setup the options album::add_option(1, 'show_license', album::OPTION_BOOL, one_time=>1, usage=>'Show the license for this plugin.'); album::add_option(2, 'epeg', album::OPTION_STR, default=>'epeg', usage=>'Name or full path to the epeg command.'); # Setup the hooks album::hook($opt,'scale', \&scale_image); return { author => 'Scott J. Bertin', href => 'mailto://scottbertin@yahoo.com', version => '1.0', description => $DESCRIPTION, }; } sub scale_image { my ($opt, $hookname, $img, $scale_arg, $new, $medium) = @_; show_license($opt) if album::option($opt, 'show_license'); # epeg can only handle JPEG return undef unless $img =~ /\.(jpg|jpeg)$/i; return undef unless $new =~ /\.(jpg|jpeg)$/i; # Is epeg available find_epeg($opt) unless $IMAGE_EPEG || $EPEG_COMMAND; return undef if !$IMAGE_EPEG && $EPEG_COMMAND eq 'NOTFOUND'; # Determine the max final size return undef unless $scale_arg =~ /^(\d+)x(\d+)/; my $maxw = $1; my $maxh = $2; my $img_x; my $img_y; my $new_x; my $new_y; if ($IMAGE_EPEG) { my $epg = new Image::Epeg($img) || return undef; $img_x = $epg->get_width(); $img_y = $epg->get_height(); ($new_x, $new_y) = get_new_size($img_x, $img_y, $maxw, $maxh); if($new_x >= $img_x || $new_y >= $img_y) { ($new_x, $new_y) = ($img_x, $img_y); copy($img, $new); } else { $epg->resize($new_x, $new_y) || return undef; $epg->write_file($new) || return undef; } } else { ($img_x, $img_y) = album::get_size($opt, $img); ($new_x, $new_y) = get_new_size($img_x, $img_y, $maxw, $maxh); if($new_x >= $img_x || $new_y >= $img_y) { ($new_x, $new_y) = ($img_x, $img_y); copy($img, $new); } else { my @args = ( $EPEG_COMMAND, "-c", "", # Avoid obnoxious epeg comment "-w", $new_x, "-h", $new_y, $img, $new ); system(@args) == 0 || return undef; } } return ($img_x, $img_y, $new_x, $new_y); } sub get_new_size { my ($img_x, $img_y, $maxw, $maxh) = @_; my ($new_x, $new_y) = ($maxw, $maxh); if($img_x*$maxh < $maxw*$img_y) { $new_x = int($img_x * $maxh/$img_y + .5); } else { $new_y = int($img_y * $maxw/$img_x + .5); } return ($new_x, $new_y); } sub find_epeg { my ($opt) = @_; $EPEG_COMMAND = album::option($opt, 'epeg'); if(defined($EPEG_COMMAND) && ! -x $EPEG_COMMAND) { my @path = album::get_path($opt); $EPEG_COMMAND = album::search_path_exec($opt,$EPEG_COMMAND,@path); } if(!$EPEG_COMMAND || ! -x $EPEG_COMMAND) { print STDERR "\nUnable to locate the epeg command. $opt->{_curr_plugin} plugin disabled\n"; print STDERR "Use the $opt->{_curr_plugin}:epeg option to specify where to find it.\n"; $EPEG_COMMAND = 'NOTFOUND'; } } sub show_license { my ($opt) = @_; print "The following license applies ONLY to the ", $opt->{_curr_plugin}, " plugin, and should not be construed ", "to apply to album, or any other plugin.\n\n", $LICENSE; exit; } # Plugins always end with: 1; From scottbertin@y... Tue Nov 22 19:29:08 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PLUGIN] audio.alp - a pluin to add playback of an audio file Message-ID: <4383E204.7050100@yahoo.com> Attached is a plugin to add playback of an audio file, such as a voice memo recorded by a digital camera. It works with album 3.10. If you have an image named pict1234.jpg (for example), this plugin will find pict1234.wav and allow it to be played on the image page. It will look for audio files in wav, aiff, au, and mid format. This plugin (ab)uses the write_images_pages hook to modify the caption on the image. It needs to be loaded before any plugin that uses the write_image_pages hook for its intended purpose. Scott J. Bertin scottbertin@yahoo.com -------------- next part -------------- # Album Plugin: captions/formatting/audio # For info: 'album -plugin_info captions/formatting/audio' # For usage: 'album -plugin_usage captions/formatting/audio' use strict; use File::Copy; my $LICENSE = << 'LICENSE'; Copyright (c) 2005 Scott J. Bertin Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. LICENSE my $DESCRIPTION = << 'DESCRIPTION'; Adds audio to image pages. This plugin needs to be loaded before any plugin that uses the write_image_pages hook for its intended purpose. DESCRIPTION my $SOUND_TYPES = "aif|AIF|aiff|AIFF|au|AU|mid|MID|wav|WAV"; my @ALIGNMENTS = ('top', 'bottom', 'center', 'baseline', 'left', 'right', 'texttop', 'middle', 'absmiddle', 'absbottom'); sub start_plugin { my ($opt) = @_; # Setup the options album::add_option(1, 'show_license', album::OPTION_BOOL, one_time=>1, usage=>'Show the license for this plugin.'); album::add_option(1, 'embed', album::OPTION_BOOL, default=>1, usage=>'Embed the sound in the page'); album::add_option(2, 'width', album::OPTION_NUM, default=>200, usage=>'Width of sound control (-1 to hide)'); album::add_option(2, 'height', album::OPTION_NUM, default=>45, usage=>'Height of sound control (-1 to hide)'); album::add_option(2, 'align', album::OPTION_STR, default=>'bottom', usage=>'Location sound control ('.join(",", @ALIGNMENTS).')'); album::add_option(2, 'autostart', album::OPTION_BOOL, default=>1, usage=>'Automatically start playing'); album::add_option(2, 'text', album::OPTION_STR, default=>'Play sound', usage=>'Text for noembed link'); # Setup the hooks album::hook($opt, 'write_image_pages', \&write_image_pages); return { author => 'Scott J. Bertin', href => 'mailto://scottbertin@yahoo.com', version => '1.0', description => $DESCRIPTION, }; } sub write_image_pages { my ($opt, $data, $hookname, $dir, $album) = @_; # Check the options show_license($opt) if album::option($opt, 'show_license'); my $slash = album::option($opt, 'slash'); my $width = album::option($opt, 'width'); my $height = album::option($opt, 'height'); my $align = album::option($opt, 'align'); my $autostart = album::option($opt, 'autostart'); my $text = album::option($opt, 'text'); my $embed = album::option($opt, 'embed'); album::usage("Unknown $opt->{_curr_plugin}:align option: $align\n". "\tShould be one of: ". join(",", @ALIGNMENTS)) unless !$width || !$height || grep(uc($align), @ALIGNMENTS); # This a bad spot to do this, but seems to be the only way to add the # audio to just the image pages. I would prefer to hook modify_caption, # but that would change the album pages also. my $data_changed = 0; foreach my $pic (@{$data->{pics}}) { my $obj = $data->{obj}{$pic}; my $basename = $data->{obj}{$pic}{full}{path}; $basename =~ s/[^\.]+$//; foreach my $ext (split(/\|/,$SOUND_TYPES)) { if (-r $basename.$ext) { my $tn = $dir.$slash.album::option($opt, 'dir'); # Windows Media Player won't use paths containing ".." #my $snd = album::url_quote($opt, # album::diff_path($opt, $tn, $basename.$ext)); $data->{obj}{$pic}{full}{file} =~ /^(.+\.)[^\.]+$/; my $snd = $1.$ext; copy($basename.$ext, $tn.$slash.$snd) unless -e $tn.$slash.$snd || link($basename.$ext, $tn.$slash.$snd); $snd = album::url_quote($opt,$snd); if ($embed) { $obj->{cap} .= '
= 0 && $height >= 0; $obj->{cap} .= ' align='.album::url_quote($opt,$align) if $align && $width && $height; $obj->{cap} .= ' autostart="true"' if $autostart; $obj->{cap} .= '>
'; $obj->{cap} .= '' if $text; } else { $obj->{cap} .= '<br>'; } $obj->{cap} .= '<a href='.$snd.'>'.$text.'</a><br>' if $text; $obj->{cap} .= '' if $text && $embed; $data_changed = 1; # Only add one sound last; } } } return 0 unless $data_changed; # Here is the really ugly part, Need to undo & redo data_to_eperl to # get the changed data to the theme. delete $data->{eperl}; delete $data->{end_eperl}; album::data_to_eperl($opt,$data); return 0; } sub show_license { my ($opt) = @_; print "The following license applies ONLY to the ", $opt->{_curr_plugin}, " plugin, and should not be construed ", "to apply to album, or any other plugin.\n\n", $LICENSE; exit; } # Plugins always end with: 1; From scottbertin@y... Tue Nov 22 18:01:18 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] [PATCH] Add an option to process child directories first Message-ID: <4383CD6E.9090400@yahoo.com> The following patch to album 3.10 adds a -children_first option to process child directories before the parent. This allows dir_image and plugins to have access to accurate information about what is in the child directories without duplicating the work album does to find it out. Scott J. Bertin scottbertin@yahoo.com Index: album =================================================================== RCS file: /Users/scottbertin/.cvsroot/album/album,v retrieving revision 1.6 diff -u -r1.6 album --- album 19 Nov 2005 12:35:05 -0000 1.6 +++ album 19 Nov 2005 14:15:53 -0000 @@ -133,6 +133,7 @@ add_option(2,'default_index', OPTION_STR, args=>'', default=>'index.html', usage=>["The file the webserver accesses when", "when no file is specified."]); add_option(3,'html', OPTION_STR, args=>'', default=>'.html', usage=>"Default postfix for HTML files"); +add_option(1,'children_first',OPTION_BOOL, usage=>"Process child directories first"); # Thumbnail Options: add_option(1,'Thumbnail Options:',OPTION_SEP); @@ -2831,6 +2832,14 @@ $data->{obj}{$dir}{cap} = $new if defined $new; $data->{obj}{$dir}{name} = clean_name($opt,$dir,$data->{obj}{$dir}{name}); + + if($data->{_children}{$dir}) { + my $child_data = $data->{_children}{$dir}; + $data->{obj}{$dir}{num_pics} = @{$child_data->{pics}} + if $child_data->{pics} && !$data->{obj}{$dir}{num_pics}; + $data->{obj}{$dir}{num_dirs} = @{$child_data->{dirs}} + if $child_data->{dirs} && !$data->{obj}{$dir}{num_dirs}; + } } } @@ -4704,28 +4713,39 @@ # Returns: Example: (album/dir/, dir/, album/dir/image.gif, image.gif) return @ret if defined $ret[0]; - $data->{obj}{$child}{num_pics} = 0; - $data->{obj}{$child}{num_dirs} = 0; - my $dir = $data->{paths}{dir}; my $child_path = "$dir/$child"; - # Basic method, choose first picture by captions.txt - # This is redundant work, we'll probably do this again when - # we traverse the child - can we cache this somewhere?? - my $child_data = new_album_data($opt,$child_path); - gather_contents($opt,$child_data); - $data->{obj}{$child}{num_dirs} = @{$child_data->{dirs}} if $child_data->{dirs}; - - return undef unless $child_data->{pics}; - get_captions($opt,$child_data); # For sorting - sort_info($opt,$child_data); - my @images = grep is_image($opt,$_), @{$child_data->{pics}}; - - $data->{obj}{$child}{num_pics} = scalar @images; + my $child_data = $data->{_children}{$child}; + my $image; + my $image_path; + if($child_data) { + $data->{obj}{$child}{num_dirs} = @{$child_data->{dirs}} if $child_data->{dirs}; + $data->{obj}{$child}{num_pics} = @{$child_data->{pics}} if $child_data->{pics}; + $image = $child_data->{pics}[0]; + $image_path = $child_data->{obj}{$image}{full}{path}; + } else { + # Basic method, choose first picture by captions.txt + # This is redundant work, we'll probably do this again when + # we traverse the child - can we cache this somewhere?? + my $child_data = new_album_data($opt,$child_path); + gather_contents($opt,$child_data); + $data->{obj}{$child}{num_dirs} = @{$child_data->{dirs}} if $child_data->{dirs}; + + return undef unless $child_data->{pics}; + get_captions($opt,$child_data); # For sorting + sort_info($opt,$child_data); + + my @images = grep is_image($opt,$_), @{$child_data->{pics}}; + + $data->{obj}{$child}{num_pics} = scalar @images; + + $image = $images[0]; + $image_path = "$child_path/$image"; + } - return undef unless @images; - ($child_path,$child,"$child_path/$images[0]",$images[0]); + return undef unless $image; + ($child_path,$child,$image_path,$image); } sub handle_child { @@ -4750,7 +4770,8 @@ get_size($opt,'thumb',$obj); # URL to find the thumbnail - $obj->{URL}{album_page}{thumb} = url_quote($opt, "$url/$opt->{dir}/$obj->{thumb}{file}"); + my $thumb_path = diff_path($opt, $data->{paths}{dir}, $obj->{thumb}{path}); + $obj->{URL}{album_page}{thumb} = url_quote($opt, $thumb_path); } # Should caption be done here? @@ -4838,7 +4859,7 @@ # How deep? my $noalb = -f "$dir/$opt->{no_album}" ? 1 : 0; figure_depth($opt,$data,$dir,$noalb,@dir_pieces); - return if $opt->{depth}>=0 && $data->{calling_depth} > $opt->{depth}; + return undef if $opt->{depth}>=0 && $data->{calling_depth} > $opt->{depth}; my $album = join('/',@{$data->{dir_pieces}}); # Deal with album.conf files @@ -4858,18 +4879,33 @@ # Print some info my $w = $opt->{hash_width} - $opt->{num_hashes} - 3 - 8; my $p = (length($album) >= $w) ? '..'.substr($album,-$w+3) : $album; - start_hashes($opt, "Images: $p"); if ($noalb || $data->{unknown}) { + start_hashes($opt, "Images: $p"); hash_msg($opt,"<".($noalb ? $opt->{no_album} : "unknown").">"); print STDERR "\nNothing to do. Call album with your photo directory as an option.\n\n" if $data->{start}; - return; + return undef; } - return hash_msg($opt,"") if $data->{unknown}; # Get the list of pics/dirs gather_contents($opt,$data); + if($opt->{children_first}) { + ######################### + # Do the children albums + ######################### + #my $first = "$opt->{topdir}/$data->{dir_pieces}[0]"; + my @add = $opt->{_album}{$dir}{add} ? @{$opt->{_album}{$dir}{add}} : (); + foreach my $child ( @{$data->{dirs}} ) { + next if -f "$dir/$child/$opt->{no_album}" || -f "$dir/$child$opt->{no_album}"; + $data->{_children}{$child} = + do_album($opt,"$dir/$child",@{$data->{dir_pieces}},$child) + unless $data->{start} && @add && !contains($child, @add); + } + } + + start_hashes($opt, "Images: $p"); + # Clean out thumbnail directory of images we don't have anymore clean_thumb_dir($opt,$data) if $opt->{clean}; @@ -4933,15 +4969,17 @@ if $opt->{image_pages} && !$did_images; stop_hashes($opt); - ######################### - # Do the children albums - ######################### - #my $first = "$opt->{topdir}/$data->{dir_pieces}[0]"; - my @add = $opt->{_album}{$dir}{add} ? @{$opt->{_album}{$dir}{add}} : (); - foreach my $child ( @{$data->{dirs}} ) { - next if -f "$dir/$child/$opt->{no_album}" || -f "$dir/$child$opt->{no_album}"; - do_album($opt,"$dir/$child",@{$data->{dir_pieces}},$child) - unless $data->{start} && @add && !contains($child, @add); + if(!$opt->{children_first}) { + ######################### + # Do the children albums + ######################### + #my $first = "$opt->{topdir}/$data->{dir_pieces}[0]"; + my @add = $opt->{_album}{$dir}{add} ? @{$opt->{_album}{$dir}{add}} : (); + foreach my $child ( @{$data->{dirs}} ) { + next if -f "$dir/$child/$opt->{no_album}" || -f "$dir/$child$opt->{no_album}"; + do_album($opt,"$dir/$child",@{$data->{dir_pieces}},$child) + unless $data->{start} && @add && !contains($child, @add); + } } ######################### @@ -4956,6 +4994,8 @@ # Returns: No return value needed pop_opts($opt) if $pushed; + + return $data } ################################################## From scottbertin@y... Sat Nov 26 13:43:24 2005 From: scottbertin@y... (Scott J. Bertin) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] Some nuances of plugins with multiple subdirectories Message-ID: <4388D6FC.40706@yahoo.com> The following behavior was not immediately apparent to me when I started writing and using plugins. I thought I'd share it with others to avoid any confusion. When running "album -plugin plugin A", all the hooks are called. Running "album A" after that will load the plugin (It was stored in A/album.conf), but will not call the pre_do_albums hook. This makes sense because A/album.conf is not read until after pre_do_albums is called. If A is a subdirectory of B, running "album B" will cause the plugin to be loaded, but the pre_do_albums, do_album_top, and end_album_top will not be called. Again, this makes sense if you think about when the album.conf file is loaded. If you are writing a plugin, I would suggest avoiding the pre_do_albums, do_album_top, and end_album_top hooks. If you must use them, warn your users that there could be problems unless the plugin is loaded at a specific point. If B/C/album.conf that also loads plugin, start_plugin will be called twice when "album B" is run. Once for directory A, and once for C. Any package level variables will retain their values from running the first directory. If B/A/D/album.conf loads album.conf, start_plugin will not be called for directory D, because it is already loaded from directory A. Fortunately, if B/E/album.conf does not load plugin, it will not be used for directory E. I've included a small plugin below that can be used to test these behaviors. Scott J. Bertin scottbertin@yahoo.com -- begin plugin -- use strict; my $count=0; sub start_plugin { my ($opt) = @_; # Setup the hooks album::hook($opt, 'pre_do_albums', \&print_hook); album::hook($opt, 'do_album_top', \&print_album_hook); album::hook($opt, 'end_album_top', \&print_album_hook); album::hook($opt, 'do_album', \&print_album_hook); album::hook($opt, 'end_album', \&print_album_hook); $count++; print STDERR "start_plugin called $count times\n"; return { author => 'Scott J. Bertin', href => 'mailto://scottbertin@yahoo.com', version => '1.0', description => 'Test plugin behavior', }; } sub print_hook { my ($opt, $hookname) = @_; print STDERR "$hookname called\n"; return undef; } sub print_album_hook { my ($opt, $data, $hookname) = @_; print STDERR "$hookname called for $data->{paths}{dir}\n"; return undef; } # Plugins always end with: 1; From album-author@d... Tue Nov 29 19:16:10 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] Some nuances of plugins with multiple subdirectories In-Reply-To: <4388D6FC.40706@yahoo.com> References: <4388D6FC.40706@yahoo.com> Message-ID: > ...running "album B" will cause the plugin to be loaded, but the > pre_do_albums, do_album_top, and end_album_top will not be called... This is a good point, and because of this I will probably be removing these hooks. Consider this fair warning. Also, thank you Scott for your excellent patches and plugins. I'll be incorporating them into the next release of album which should go out in about a week. :) > If B/C/album.conf that also loads plugin, start_plugin will be called > twice when "album B" is run. Once for directory A, and once for C. Any This is all true and a good point, start_plugin code should probably be prepared to be called multiple times - or do people think I should add code to avoid this situation? Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From album-author@d... Mon Dec 5 05:19:42 2005 From: album-author@d... (David Ljung Madison) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] Plugin Categories Message-ID: I'm hoping to come up with a semi-comprehensive list of plugin categories so that I can figure out where to add plugins as they're created. I think a one or two-level structure should probably be enough, hopefully. Here are some thoughts of some things that plugins could do: Caption altering: exif, formatting, purchase links Databases (for images, for captions, for ??...) Alternate image storage methods Image handling (alternate cropping, scaling, etc..) Image manipulation (watermarks, etc..) Video and other non-image manipulation? Utilities Interfaces HTML? (i.e., a mouseover EXIF dialog, etc..) Directory thumbnailing? (not sure where to put these) Sorting? Here's where I need the help - can anyone think of: A) Other types of plugins that aren't listed above? B) A classification system? Maybe just a two-level deep list of categories? Dave --------------------------------------------------------------------------- Dave Ljung Madison http://GetDave.com/ 415 341-5555 ------------ "Preferred over shiny round objects 2-to-1" ------------------ From calnevacars@g... Thu Dec 29 13:33:39 2005 From: calnevacars@g... (Lars Jensen) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] control breadcromb links Message-ID: <43B45633.2060602@gmail.com> How do I control the breadcrumb links in the upper left hand corner of the screen? I have a cygwin install, and I can't figure out how the links are generated. I'm using the BigMaste theme, and see the following i the upper left hand of the screen: Album: home::ljensen::tmp::webpages::vacation I only want to see the last link (vacation). Thanks, Lars. From album@d... Fri Dec 30 05:50:19 2005 From: album@d... (Jon Daley) Date: Thu Dec 21 19:59:34 2006 Subject: [Album] control breadcromb links In-Reply-To: <43B45633.2060602@gmail.com> References: <43B45633.2060602@gmail.com> Message-ID: In album.th you should have a call to: <:print Parent_Albums(":"):> I don't know the name of the function call that you want, but it should be pretty easy to find the function to print only the current album. On Thu, 29 Dec 2005, Lars Jensen wrote: > How do I control the breadcrumb links in the upper left hand corner of the > screen? I have a cygwin install, and I can't figure out how the links are > generated. I'm using the BigMaste theme, and see the following i the upper > left hand of the screen: > > Album: home::ljensen::tmp::webpages::vacation > > I only want to see the last link (vacation). > > Thanks, > Lars. > > > _______________________________________________ > Album mailing list > Album@marginalhacks.com > http://marginalhacks.com/mailman/listinfo/album > ************************************** Jon Daley http://jon.limedaley.com/ All things are possible to him that believeth. -- Mark 9:23