One of the neat features of Chameleon is that it offers the album composer so many choices/styles. Unfortunately, the album composer is not always the album viewer and the composer's choice of style(s) might not match the choice of the viewer(s). Wouldn't it be neat if the composer could let the viewers choose from any of the many Chameleon styles?
It would be nice if the album composer could just work in one (original) style and have tools to automate the creation of some or all of the alternatives. It would be nicer if the styles could be hyperlinked together so that one could view any slide or index in any alternate style with a single click.
The attached files implement such a solution. Unfortunately (for some), the scripts are written in the bash shell so this means that you need to be running a UNIX variant or have Cygwin installed on your Windows machine (see www.cygwin.com - it's free, it's great!).
Actually, the scripts work best on UNIX filesystems because much of the original content can be referenced _very_ cheaply (in time and space) using symbolic links. If you will be hosting the albums on a UNIX (Web server?) machine, it is best if you can create the albums with symbolic links. If this is not possible, copies of the original album content will be made. In this case, you may want to have JAlbum link to the original images to cut down on on the original album size.
Here is an example on how I use the attached files.
First, I use albuminfo.inc.ross.3 to replace the albuminfo.inc file under the Chameleon skin in the JAlbum installation. This allows for an easy way to hyperlink the albums together. I am hoping Laza will include this feature in future releases.
On the main tab, I like to check "Link to originals" to keep the album size down (this is not required). I always distribute the albums with the originals. Choose the Chameleon skin and any style (say, Black.css). I let my Output directory reflect the skin/style album so I name it Chameleon.Black.album. If the album is under the image directory, be sure to exclude this and the to-be-generated albums from consideration by including the .*\.album pattern in the Advanced : Ignore pattern.
On the Chameleon tab, use the Custom links to specify something like this:
Name: Previous Skin/Style
0 Open in new window
Name: Next Skin/Style
0 Open in new window
Clicking on these links will move the user through a circularly linked set of skin/styles for the current index or slide. This is a great way to evaluate which style looks best.
Make the album and save the settings in the album (File : Save project in album).
Run the jastyles script to create all Chameleon alternate style variants from this one album. I use the verbose option of the command to monitor its progress. Use the --man or --help options (or see the script!) for more info.
This command will run relatively quickly on a UNIX filesystem but will be slower on Windows because files need to be copied instead of simply referenced (and Windows is just slower).
Note that the outputDirectory's follow the same naming pattern I chose for the original album (some coincidence). When browsing the album, these names will be presented in the page URLs so I gave them meaningful names.
Instead of creating them all, the builder may choose to limit the set of styles by naming only those of interest. For example,
$ jastyles -v Chameleon.Black.album/jalbum-settings.jap Black Coffee Aqua_dark
Once the set of album skin/styles are created, we can link them together in any order we want. Here is how the jslink command may be used to order them alphabetically, forward and reverse. If you want, you can specify any order on the command line. Again, I like the verbose option so I can see what is happening:
Note that the names chosen (_forward.html and _reverse.html) are the same names used in the Chameleon custom links. Note also that they begin with an underscore because jastyles will not clone files that begin with and underscore (these files are different for each album).
Except for the hyperlinks, the capabilities described above are not unique for the Chameleon skin. For example, I create one Chameleon skin/style album and one Slide show skin/style album from the same images. As long as the thumbnail layout parameters are the same in these albums, they will both have the same HTML index and slide pages. So, we can hyperlink from any Chameleon slide or index to the corresponding page in the Slide show album using the techniques described above. Unfortunately, since the Slide show skin does not support hyperlinks like Chameleon, we will not be able to hyperlink back but one may use the back feature of the browser to go back to the Chameleon skin.
The jastyles tool can be used to create all Slide show styles. Actually, it can be used to create all styles for any skin whose style dependent content is restriced to its resourceDirectory.
I wonder if a simpler method could be devised using the rel="alternate stylesheet" attribute of the html link element?
An example (non JAlbum) can be seen at http://www.csszengarden.com/?cssfile=/195/195.css&page=0
I haven't looked closely at how easily this can be implemented with Chameleon or other JAlbum skins, but it seems to me that as long as you can ensure unique pathnames for elements having the same name in different styles this would be doable.
The advantages would be
#1 only one set of html pages (therefore only one pass of JAlbum)
#2 cross platform
#3 cross browser (Firefox already has built-in support, but other browsers can be catered for by including a "style switcher"mechanism in the page as is done in the example.
...but it won't help when working with different skins (e.g. Chameleon and Slide show as I described above). The problem I originally set out to solve was inter-skin/style hyperlinking (using my albuminfo.inc and jslink). I believe that the approach that I have taken is necessary to solve this problem. I just hope that Laza adopts the new albuminfo.inc.
Once I recognized the potential for intra-skin/style hyperlinking, I saw the benefit of quickly churning out the style dependent resourceDirectories and applying them to the same content using symbolic links or copies. Once these clones were in place, I could use my inter-skin/style linking solution to provide intra-skin/style links.
Such cloning on file systems supporting symbolic links is very cheap. But, as I mentioned, the links need to be rebuilt if top-level names change and, as you mentioned, it is not a cross-platform solution. For a cross-platform solution one needs to make copies. BTW, this can be forced on the jastyles tool by setting the CYGWIN_ROOT environment variable:
CYGWIN_ROOT=1 jastyles ...
Perhaps there should be a jastyles command line option for this.
There would still be the need to churn out style dependent resourceDirectories. Maybe that means a smarter jastyles utility.
Somehow I missed your second post regarding an inter-skin impementation of the idea.
Yes, the "alternate stylesheet" idea would not work with different skins.
And it is perhaps a little more complicated than my brief outline might suggest.That was just a quick reaction to encourage further discussion.
For the "alternate stylesheet" method, we would possibly need some extra template variables, e.g. to identify paths to the various stylesheets.
And as different styles can use different navigation gifs, we would need a method of switching those paths as well.
Not as simple as it first seemed
I checked out the link you gave in your first post. Certainly their solution includes a way to have different images for each style. I looked further and on their FAQ they say:
Why a page refresh when loading new styles?
HMMM, I need a client side method because I am archiving to CDs and distributing this way. My existing solution works well for a UNIX server side solution (using symbolic links).
Reading further in the FAQ:
How are you switching style sheets like that?
I (think I) am beginning to understand the problem better.
It seems to me that any solution to this problem would be very invasive to the skin (require a lot of skin changes). Either the skin would have to be changed to get all resources through the style sheet or the way resources are retrieved would have to use some kind of switch.
Yes, I don't think this can be achieved purely through CSS.
I don't think that images other than background images can be specified through CSS, so any navigation icons, for instance, that need to change will have to be addressed by some html mechanism.
One possibility would be to have the icons as background images to transparent gif placeholders, but that of course also means changes to the template files.
For skins like BluPlusPlus and Aeneid where the icon sets are not specified as part of the style, this might not present such a problem, but album builders typically choose an icon-set that matches their style, so you would have to choose an icon-set that matches all the styles you want to include.You might also want to change (XBF) frames when you change styles.
It seems to me that any solution to this problem
would be very invasive to the skin (require a lot of
skin changes). Either the skin would have to be
changed to get all resources through the style sheet
or the way resources are retrieved would have to use
some kind of switch.
And it still doesn't address your aim of a cross-skin solution. The skins are so different that you definitely need different html pages for each skin.
Yes, that is virtually the same as my suggestion of using the icon graphic as a background image. The one difference (using a common background graphic, and text instead of the transparent gif) would mean that none of the icons currently used would be suitable.
I have uploaded a preliminary sample of what a viewer-selectable multi-style (but not multi-skin) album might look like.
I have moved page background and title-bar images to stylesheets instead of inline styles.
I have not yet changed the navigation icons to background images, so all the navigation icons are currently from the "black" style.
This has been modified by editing the CSS and the HTML from JAlbum output, not by editing the template, so is a "proof of concept" rather than a solution.
From recent comments by laza, I don't think he wants to make big changes to Chameleon, so this thread might be better in "General Skins and Filters", "General Development", or "General Discussion". I can move it there if you like.
But I understand why Laza may not want to change Chameleon to support this - is sounds like a lot of work. I believe that it would show off his work better, however. I wonder if he would accept help in doing this work.
The reason I posted to this forum was because of related posts I have made regarding suggested changes to Laza's albuminfo.inc. To make my inter/intra-skin/style switching work one would require changes like the latest ones I have posted here. I was hoping that Laza would not see this as a major change and incorporate it for the benefit of all.
Of course, ultimately, the decision is Laza's. I
The jastyles and jslink utilities I have posted might have general benefit for other skin users. For skin/style switching, they only require the ability to insert custom hyperlinks (a la Chameleon/albuminfo.inc.ross.3) on each page. The Chameleon method may serve as an example on how to do this.
If you and/or Laza feel it is best to move this thread then please do so. I just want to make sure that this issue is considered by Laza.
Yes, many people put a lot of thought into choosing a style that suits the pictures that they are showing and would not think it appropriate to allow surfers to monkey around with a carefully designed look and feel.
On the other hand, sometimes there may be two or three styles that show off a given set of pictures to advantage, and the album builder does have the ability to choose which styles are included in the mix.
Another possible drawback is that designers of existing skins may not want to spend time making the necessary changes to make this possible. Perhaps someone might like to develop a new skin with this feature?
However, it seems that buttons are restricted to
The restriction to rectangular buttons only applies to "pure" CSS buttons, i.e. using plain text with background colour. For CSS background images, the restriction does not apply.