reply; disambiguate who said what
parent
2ceb056f53
commit
ca2b8306ac
|
@ -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
|
||||
>>> 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
|
||||
|
@ -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.
|
||||
>>>>
|
||||
>>>> --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
|
||||
|
@ -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.
|
||||
>>> --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.
|
||||
>>>> --k
|
||||
|
||||
>>> 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?
|
||||
>>> --s
|
||||
|
||||
>>> * 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
|
||||
>>>> 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
|
||||
|
@ -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.
|
||||
>>>> --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.
|
||||
>>>> --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
|
||||
|
@ -754,6 +790,10 @@ My wishlist for the plugin would include:
|
|||
>>>>
|
||||
>>>> --[[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
|
||||
|
|
Loading…
Reference in New Issue