aboutsummaryrefslogtreecommitdiff
path: root/doc/plugins/contrib
diff options
context:
space:
mode:
authorhttp://smcv.pseudorandom.co.uk/ <http://smcv.pseudorandom.co.uk/@web>2010-05-09 18:27:58 +0000
committerJoey Hess <joey@finch.kitenet.net>2010-05-09 18:27:58 +0000
commit3f7ef01ca22963dc253d76a27a711dd18998606c (patch)
tree3801c03c66d0d784243dae5c30066e6a59f51eb8 /doc/plugins/contrib
parent0594ea04a811a59120ea7e91e94c3389ffcd33ca (diff)
downloadikiwiki-3f7ef01ca22963dc253d76a27a711dd18998606c.tar
ikiwiki-3f7ef01ca22963dc253d76a27a711dd18998606c.tar.gz
respond with better design
Diffstat (limited to 'doc/plugins/contrib')
-rw-r--r--doc/plugins/contrib/album/discussion.mdwn41
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,