X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/1c044400184648cbb511b796ad0499e53b21d084..f7601954a862afd4c5a5b9ba83480af0472e1cf9:/doc/plugins/contrib/album/discussion.mdwn?ds=sidebyside diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn index 7a3c19cf6..5c8e74fa6 100644 --- a/doc/plugins/contrib/album/discussion.mdwn +++ b/doc/plugins/contrib/album/discussion.mdwn @@ -51,3 +51,206 @@ 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 > playing with a normal IkiWiki installation for a bit, then trying > out this plugin when you've mastered the basics of IkiWiki. --[[smcv]] + +---- + +You had wanted my feedback on the design of this. I have not looked at the +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. + +> There's already a script (ikiwiki-album) to populate a git +> checkout with skeleton "viewer" pages; I was planning to make a +> specialized CGI interface for albums after getting feedback from +> you (since the requirements for that CGI interface change depending +> on the implementation). I agree that this is ugly, though. -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! + +> 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). +> -s + +>> I think that with the new dependency types system, the dependencies for +>> these can be presence dependencies, which will probably help with +>> avoiding rebuilds of a page if the next/prev page is changed. +>> (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]] + +* 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. + +> albumsections are just a way to insert headings into the flow of +> photos, so they don't actually affect dependencies. +> +> One non-obvious constraint of ikiwiki's current design is that +> everything "off-page" necessary to build any page has to happen +> at scan time, which has caused a few strange design decisions, +> like the fact that each viewer controls what album it's in. +> +> It's difficult for the contents of the album to just be a +> pagespec, like for inline, because pagespecs can depend on +> metadata, which is gathered in arbitrary order at scan time; +> so the earliest you can safely apply a pagespec to the wiki +> contents to get a concrete list of pages is at rebuild time. +> +> (This stalled my attempt at a trail plugin, too.) -s + +>> Not sure I understand why these need to look at pagespecs at scan time? +>> Also, note that it is fairly doable to detect if a pagespec uses such +>> metadata. Er, I mean, I have a cheezy hack in `add_depends` now that does +>> it to deal with a similar case. --[[Joey]] + +* One thing I do like about having individual pages per image is + that they can each have their own comments, etc. + +> Yes; also, they can be wikilinked. I consider those to be +> UI requirements. -s + +* Seems possibly backwards that the albumimage controls what album + an image appears in. Two use cases -- 1: I may want to make a locked + 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). + +> See note above about pagespecs not being very safe early on. +> You did merge my inline-with-pagenames feature, which is safe to use +> at scan time, though. + +* 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 + page. Plus some way I can, later, edit metadata for captions, + 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. + +> 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 +> by plugins, and things could be changed to respect it. +> +> 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 +> to be rebuilt, but in practice that happens anyway). -s +> +>> Yes, that would make some sense.. It also allows putting one image in +>> two albums, with different caption etc. (Maybe for different audiences.) +>> +>> It would probably be possible to add a new dependency type, and thus +>> make ikiwiki smart about noticing whether the metadata has actually +>> changed, and only update those viewers where it has. But the dependency +>> type stuff is still very new, and not plugin friendly .. so only just +>> possible, --[[Joey]] + +---- + +Trying to use the "special extension" design: + +Suppose that each viewer is a JPEG-or-GIF-or-something, with extension +".albumimage". We have a gallery "memes" with three images, badger, +mushroom and snake. + +> An alternative might be to use ".album.jpg", and ".album.gif" +> etc as the htmlize extensions. May need some fixes to ikiwiki to support +> that. --[[Joey]] + +Files in git repo: + +* index.mdwn +* memes.mdwn +* memes/badger.albumimage (a renamed JPEG) +* memes/badger/comment_1._comment +* memes/badger/comment_2._comment +* memes/mushroom.albumimage (a renamed GIF) +* memes/mushroom.meta (sidecar file with metadata) +* memes/snake.albumimage (a renamed video) + +Files in web content: + +* index.html +* memes/index.html +* memes/96x96-badger.jpg (from img) +* memes/96x96-mushroom.jpg (from img) +* memes/96x96-snake.jpg (from img, hacked up to use totem-video-thumbnailer :-) ) +* memes/badger/index.html (including comments) +* memes/badger.jpg +* memes/mushroom/index.html +* memes/mushroom.gif +* memes/snake/index.html +* memes/snake.mov + +ispage("memes/badger") (etc.) must be true, to make the above rendering +happen, so albumimage needs to be a "page" extension. + +To not confuse other plugins, album should probably have a filter() hook +that turns .albumimage files into HTML? That'd probably be a reasonable +way to get them rendered anyway. + +> I guess that is needed to avoid preprocess, scan, etc trying to process +> the image, as well as eg, smiley trying to munge it in sanitize. +> --[[Joey]] + +do=edit&page=memes/badger needs to not put the JPG in a text box: somehow +divert or override the normal edit CGI by telling it that .albumimage +files are not editable in the usual way? + +Every image needs to depend on, and link to, the next and previous images, +which is a bit tricky. In previous thinking about this I'd been applying +the overly strict constraint that the ordered sequence of pages in each +album must be known at scan time. However, that's not *necessarily* needed: +the album and each photo could collect an unordered superset of dependencies +at scan time, and at rebuild time that could be refined to be the exact set, +in order. + +> Why do you need to collect this info at scan time? You can determine it +> at build time via `pagespec_match_list`, surely .. maybe with some +> memoization to avoid each image in an album building the same list. +> I sense that I may be missing a subtelty though. --[[Joey]] + +Perhaps restricting to "the images in an album A must match A/*" +would be useful; then the unordered superset could just be "A/*". Your +"albums via tags" idea would be nice too though, particularly for feature +parity with e.g. Facebook: "photos of Joey" -> "tags/joey and albumimage()" +maybe? + +If images are allowed to be considered to be part of more than one album, +then a pretty and usable UI becomes harder - "next/previous" expands into +"next photo in holidays/2009/germany / next photo in tagged/smcv / ..." +and it could get quite hard to navigate. Perhaps next/previous links could +be displayed only for the closest ancestor (in URL space) that is an +album, or something? + +> Ugh, yeah, that is a problem. Perhaps wanting to support that was just +> too ambitious. --[[Joey]] + +Requiring renaming is awkward for non-technical Windows/Mac users, with both +platforms' defaults being to hide extensions; however, this could be +circumvented by adding some sort of hook in attachment to turn things into +a .albumimage at upload time, and declaring that using git/svn/... without +extensions visible is a "don't do that then" situation :-) + +> Or extend `pagetype` so it can do the necessary matching without +> renaming. Maybe by allowing a subdirectory to be specified along +> with an extension. (Or allow specifying a full pagespec, +> but I hesitate to seriously suggest that.) --[[Joey]] + +Ideally attachment could also be configured to upload into a specified +underlay, so that photos don't have to be in your source-code control +(you might want that, but I don't!). + +Things that would be nice, and are probably possible: + +* make the "Edit page" link on viewers divert to album-specific CGI instead + of just failing or not appearing +* some way to deep-link to memes/badger.jpg with a wikilink, without knowing a + priori that it's secretly a JPEG