X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/969ce8c5f889f8f2696c3ed4995f021b2a6539e1..d86f248329b1702c5093e0bd8274c3bd3f059ba8:/doc/plugins/contrib/album/discussion.mdwn?ds=inline diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn index 50d6c8ddd..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 @@ -69,7 +73,20 @@ code or tried it yet, but here goes. --[[Joey]] > on the implementation). I agree that this is ugly, though. -s >> Would you accept a version where the albumimage "viewer" pages ->> could be 0 bytes long, at least until metadata gets added? -s +>> could be 0 bytes long, at least until metadata gets added? +>> +>> The more I think about the "binaries as first-class pages" approach, +>> the more subtle interactions I notice with other plugins. I +>> think I'm up to needing changes to editpage, comments, attachment +>> and recentchanges, plus adjustments to img and Render (to reduce +>> duplication when thumbnailing an image with a strange extension +>> while simultaneously changing the extension, and to hardlink/copy +>> 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 @@ -85,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 @@ -133,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 @@ -149,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 @@ -186,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 @@ -205,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]] @@ -220,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, @@ -350,6 +390,10 @@ underlay, so that photos don't have to be in your source-code control > Replying to myself: perhaps best done as an orthogonal extension > to attach? -s +> Yet another non-obvious thing this design would need to do is to find +> some way to have each change to memes/badger._albummeta show up as a +> change to memes/badger in `recentchanges`. -s + Things that would be nice, and are probably possible: * make the "Edit page" link on viewers divert to album-specific CGI instead