reply; disambiguate who said what

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

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 70fcf4924851b34521278fa81c7ba36ebdce04e3..b7c9b009509f3e48e4f7ccd023a012e995c71332 100644 (file)
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -649,7 +649,7 @@ My wishlist for the plugin would include:
 >>> In the current (album5) design, the viewer pages that are automatically
 >>> created to go alongside the pictures are basically stand-ins for the
 >>> pictures, as far as metadata, wikilinks, tags and other "first-class
 >>> In the current (album5) design, the viewer pages that are automatically
 >>> created to go alongside the pictures are basically stand-ins for the
 >>> pictures, as far as metadata, wikilinks, tags and other "first-class

->>> wiki page" things are concerned.
+>>> wiki page" things are concerned. --s

 
 >>>> I can see why it's important to keep these models simple and have figured out
 >>>> that the viewer pages are stand-ins for the image. Just as a tought though. If 
 
 >>>> I can see why it's important to keep these models simple and have figured out
 >>>> that the viewer pages are stand-ins for the image. Just as a tought though. If 


@@ -661,6 +661,15 @@ My wishlist for the plugin would include:
 >>>> One thing to point out is that last time I tried pages can be members of 
 >>>> arbitrary numbers of trails/albums. You just get multiple rows of navigation, one
 >>>> for each trail. This doesn't quite work as it's hard to know which one to click.
 >>>> One thing to point out is that last time I tried pages can be members of 
 >>>> arbitrary numbers of trails/albums. You just get multiple rows of navigation, one
 >>>> for each trail. This doesn't quite work as it's hard to know which one to click.

+>>>>
+>>>> --k
+
+>>>>> Pages can be part of arbitrarily many trails, yes - that's a consequence of
+>>>>> how trails are created. If you can think of a better way to present a page
+>>>>> that's in more than one trail, I'd welcome ideas... I did originally have an
+>>>>> implementation where only one trail would generate links, but when I tried
+>>>>> it on some (rather artificial) overlapping trails, the result was more
+>>>>> confusing. --s

 
 >>> If there are to be viewer pages elsewhere in the wiki, I don't think
 >>> inheriting the picture's metadata is desired. Suppose you have a
 
 >>> If there are to be viewer pages elsewhere in the wiki, I don't think
 >>> inheriting the picture's metadata is desired. Suppose you have a


@@ -672,10 +681,12 @@ My wishlist for the plugin would include:
 >>> times - once is enough, there's only one actual photo after all. So
 >>> I think the "main" viewer page should be the only one that has
 >>> the taglinks for people/alice, people/bob, places/exampleton.
 >>> times - once is enough, there's only one actual photo after all. So
 >>> I think the "main" viewer page should be the only one that has
 >>> the taglinks for people/alice, people/bob, places/exampleton.

+>>> --s

 
 >>>> The problem exposed by the tag page issue is very tricky. As you'd
 >>>> probably want the exif info, captions and titles to transfer. Just not 
 >>>> necessarily the tags.
 
 >>>> The problem exposed by the tag page issue is very tricky. As you'd
 >>>> probably want the exif info, captions and titles to transfer. Just not 
 >>>> necessarily the tags.

+>>>> --k

 
 >>> My next question is, should the viewer page representing that
 >>> particular picture in its context of "pictures near Exampleton"
 
 >>> My next question is, should the viewer page representing that
 >>> particular picture in its context of "pictures near Exampleton"


@@ -683,6 +694,7 @@ My wishlist for the plugin would include:
 >>> previous picture near Exampleton, regardless of whether it was
 >>> on an earlier or later visit) be a first-class wiki page
 >>> at all?
 >>> previous picture near Exampleton, regardless of whether it was
 >>> on an earlier or later visit) be a first-class wiki page
 >>> at all?

+>>> --s

 
 >>> * Does it make any sense to comment on "this picture in this
 >>>   context", if your wiki has comments, or should the only
 
 >>> * Does it make any sense to comment on "this picture in this
 >>>   context", if your wiki has comments, or should the only


@@ -714,7 +726,19 @@ My wishlist for the plugin would include:
 
 >>>> One thing to consider is the built in difference between the original and 
 >>>> the secondary inferred by the fact that the first is an `album` the second
 
 >>>> One thing to consider is the built in difference between the original and 
 >>>> the secondary inferred by the fact that the first is an `album` the second

->>>> an `inline`
+>>>> an `inline` --k
+
+>>>>> I had assumed that both the "original" album (the one where the picture
+>>>>> is physically located), and any other places you wanted to display it,
+>>>>> would be some other directive whose implementation includes a call to
+>>>>> `preprocess_inline`. `inline` on its own is not enough to create
+>>>>> viewer pages to display the pictures, regardless of whether you
+>>>>> want them to be one-per-picture or many-per-picture, and I'm not
+>>>>> going to wedge yet more functionality into that plugin :-)
+>>>>>
+>>>>> It might be a good idea for the thing that displays pictures not
+>>>>> physically located below that point to be a different directive, yes.
+>>>>> --s

 
 >>>> ### Single viewer 
 >>>> For my own usecase what you describe makes sense. I see the content of an inline object
 
 >>>> ### Single viewer 
 >>>> For my own usecase what you describe makes sense. I see the content of an inline object


@@ -730,12 +754,24 @@ My wishlist for the plugin would include:
 >>>> secondary viewers can be used as the title, caption etc might fit some contexts 
 >>>> better than others. Personally this is fine as I see these inline based albums as 
 >>>> compositions or views on existing content.
 >>>> secondary viewers can be used as the title, caption etc might fit some contexts 
 >>>> better than others. Personally this is fine as I see these inline based albums as 
 >>>> compositions or views on existing content.

+>>>> --k
+>>>>
+>>>>> This is basically what I thought at first, but I realised while
+>>>>> writing my earlier comments that it would be necessary
+>>>>> to hack up [[plugins/trail]] fairly seriously to make it produce
+>>>>> a trail through things that are not first-class wiki pages, and
+>>>>> I'm not sure how much it would be necessary to subvert the
+>>>>> rendering pipeline to get the right parentlinks and so on. --s

 >>>>
 >>>> ###Multiple viewers alternative
 >>>> The alternative is having a page say in `/story/album.mdwn` with the following directive
 >>>> \[[!inline  pages="/01/IMGP6494 or /02/IMGP6601 or /04/IMGP6922" sort="title"  show="0" template="albumitem"]]
 >>>> that creates new fully fledged editable viewers for each image in `/story/album/'
 >>>> without tags being auto populated but backlinks to the original album viewer.
 >>>>
 >>>> ###Multiple viewers alternative
 >>>> The alternative is having a page say in `/story/album.mdwn` with the following directive
 >>>> \[[!inline  pages="/01/IMGP6494 or /02/IMGP6601 or /04/IMGP6922" sort="title"  show="0" template="albumitem"]]
 >>>> that creates new fully fledged editable viewers for each image in `/story/album/'
 >>>> without tags being auto populated but backlinks to the original album viewer.

+>>>> --k
+>>>>
+>>>>> It can't *only* be an inline, because an inline wouldn't generate the
+>>>>> viewer pages, but I see what you mean. --s

 >>>> 
 >>>> This would make the viewers completely independent allowing for unique titles, captions and comments
 >>>> depending on context. Very useful when creating powerpoint like slideshows where you might need 
 >>>> 
 >>>> This would make the viewers completely independent allowing for unique titles, captions and comments
 >>>> depending on context. Very useful when creating powerpoint like slideshows where you might need 


@@ -754,6 +790,10 @@ My wishlist for the plugin would include:
 >>>>
 >>>> --[[kjs]]
 
 >>>>
 >>>> --[[kjs]]
 

+I've added "--k" to some of your comments so other readers (possibly including
+my future self) can keep track of our conversation, I hope you don't mind :-)
+--s
+

 ----
 
 ## cbaines' CSS changes
 ----
 
 ## cbaines' CSS changes