add changelog for externalink

[git.ikiwiki.info.git] / doc / plugins / contrib / album / discussion.mdwn

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 9720589b46cf4c488a552b4c4678cddf160274d2..0356860d8302389156a6b0a2d639645284dd8570 100644 (file)
--- 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]]
 
 >
 > --[[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
 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
 
 >> 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
 * 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]]
 
 >> (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
 * 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
 > 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
 > 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
 > (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
 
 > 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
 * 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
 
 >> 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
 > 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
 
 >> (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]]
 >> 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,
 
 Suppose that each viewer is a JPEG-or-GIF-or-something, with extension
 ".albumimage". We have a gallery "memes" with three images, badger,