diff options
| -rw-r--r-- | doc/plugins/contrib/album/discussion.mdwn | 41 |
1 files changed, 36 insertions, 5 deletions
diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn index 9720589b4..0356860d8 100644 --- a/doc/plugins/contrib/album/discussion.mdwn +++ b/doc/plugins/contrib/album/discussion.mdwn @@ -46,6 +46,10 @@ secondly: barring the CGI interface for editing the album, which would be great, > > --[[smcv]] +>> In the current version of the branch, the viewer pages are +>> generated automatically if you didn't generate them yourself, +>> so `ikiwiki-album` is no longer needed. --[[smcv]] + i'm new to ikiwiki, apologies if this is dealt with elsewhere. -brush > This plugin is pretty ambitious, and is unfinished, so I'd recommend @@ -80,6 +84,10 @@ code or tried it yet, but here goes. --[[Joey]] >> an image with a strange extension to a differing target filename >> with the normal extension, respectively). -s +>>> Now that we have `add_autofile` I can just create viewer pages +>>> whenever there's an image to view. The current version of the +>>> branch does that. -s + * With each viewer page having next/prev links, I can see how you were having the scalability issues with ikiwiki's data structures earlier! -J @@ -94,6 +102,8 @@ code or tried it yet, but here goes. --[[Joey]] >> (Unless you use img to make the thumbnails for those links, then it >> would rebuild the thumbnails anyway. Have not looked at the code.) --[[Joey]] +>>> I do use img. -s + * And doesn't each viewer page really depend on every other page in the same albumsection? If a new page is added, the next/prev links may need to be updated, for example. If so, there will be much @@ -142,13 +152,20 @@ code or tried it yet, but here goes. --[[Joey]] > one album: if they're subpages of 2+ nested albums then they're only > considered to be in the deepest-nested one (i.e. longest URL), and if > they're not in any album then that's a usage error. This would -> also make prev/next links sane. -> +> also make prev/next links sane. -s + +>> The current version constrains images to be in at most one album, +>> choosing one arbitrarily (dependent on scan order) if albums are +>> nested. -s + > If you want to reference images from elsewhere in the wiki and display > them as if in an album, then you can use an ordinary inline with > the same template that the album would use, and I'll make sure the -> templates are set up so this works. -> +> templates are set up so this works. -s + +>> Still needs documenting, I've put it on the TODO list on the main +>> page. -s + > (Implementation detail: this means that an image X/Y/Z/W/V, where X and > Y are albums, Z does not exist and W exists but is not an album, > would have a content dependency on Y, a presence dependency on Z @@ -158,6 +175,12 @@ code or tried it yet, but here goes. --[[Joey]] > subpages of the album, although that would mean breaking some URLs > on the existing website I'm doing all this work for... -s +>> The current version of the branch doesn't have this restriction; +>> perhaps it's a worthwhile simplification, or perhaps it's too +>> restrictive? I fairly often use directory hierarchies like +>> `a_festival/saturday/foo.jpg` within an album, which makes +>> it very easy to write `albumsection` filters. -s + * Putting a few of the above thoughts together, my ideal album system seems to be one where I can just drop the images into a directory and have them appear in the album index, as well as each generate their own wiki @@ -195,6 +218,10 @@ code or tried it yet, but here goes. --[[Joey]] >> upload-and-rename. >> -s +>>> I believe the current branch meets your requirements, by having +>>> first-class wiki pages spring into existence using `add_autofile` +>>> to be viewer pages for photos. -s + > In a way, what you really want for metadata is to have it in the album > page, so you can batch-edit the whole lot by editing one file (this > does mean that editing the album necessarily causes each of its viewers @@ -214,6 +241,9 @@ code or tried it yet, but here goes. --[[Joey]] >> (That's apparently good enough for Bugzilla, but not really >> for ikiwiki). -s +>>> This is now in the main page's TODO list; if/when I implement this, +>>> I intend to make it a specialized CGI interface. -s + >> Yes, [all metadata in one file] would make some sense.. It also allows putting one image in >> two albums, with different caption etc. (Maybe for different audiences.) >> --[[Joey]] @@ -229,7 +259,8 @@ code or tried it yet, but here goes. --[[Joey]] ---- -Trying to use the "special extension" design: +'''I think the "special extension" design is a dead-end, but here's what +happened when I tried to work out how it would work. --[[smcv]]''' Suppose that each viewer is a JPEG-or-GIF-or-something, with extension ".albumimage". We have a gallery "memes" with three images, badger, |