X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/cd5bf7eb7f74c2414a87c77141ed0c502ff7f464..eb58b51bb0d006f8e81a8c8a2b9913a0d7d4087f:/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 156cd7ad8..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 @@ -60,7 +64,7 @@ code or tried it yet, but here goes. --[[Joey]] * Needing to create the albumimage "viewer" pages for each photo seems like it will become a pain. Everyone will need to come up with their own automation for it, and then there's the question - of how to automate it when uploading attachments. + of how to automate it when uploading attachments. -J > There's already a script (ikiwiki-album) to populate a git > checkout with skeleton "viewer" pages; I was planning to make a @@ -69,11 +73,24 @@ 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 - earlier! + earlier! -J > Yeah, I think they're a basic requirement from a UI point of view > though (although they don't necessarily have to be full wikilinks). @@ -85,10 +102,12 @@ 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 - unnecessary rebuilding. + unnecessary rebuilding. -J > albumsections are just a way to insert headings into the flow of > photos, so they don't actually affect dependencies. @@ -117,7 +136,7 @@ code or tried it yet, but here goes. --[[Joey]] >>> have no idea what it depends on until the rebuild phase. -s * One thing I do like about having individual pages per image is - that they can each have their own comments, etc. + that they can each have their own comments, etc. -J > Yes; also, they can be wikilinked. I consider those to be > UI requirements. -s @@ -127,19 +146,26 @@ code or tried it yet, but here goes. --[[Joey]] album, but then anyone who can write to any other page on the wiki can add an image to it. 2: I may want an image to appear in more than one album. Think tags. So it seems it would be better to have the album - directive control what pages it includes (a la inline). + directive control what pages it includes (a la inline). -J > I'm inclined to fix this by constraining images to be subpages of exactly > 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 @@ -156,7 +188,7 @@ code or tried it yet, but here goes. --[[Joey]] etc. (Real pity we can't just put arbitrary metadata into the images themselves.) This is almost pointing toward making the images first-class wiki page sources. Hey, it worked for po! :) But the metadata and editing - problems probably don't really allow that. + problems probably don't really allow that. -J > Putting a JPEG in the web form is not an option from my point of > view :-) but perhaps there could just be a "web-editable" flag supplied @@ -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