X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/50c400f0c447e58f9357620066636b6a17f9eeaa..96566c33a79a1628a75bc573d924fd3be8b6b37d:/doc/plugins/contrib/album/discussion.mdwn diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn index 70fcf4924..23ff9017d 100644 --- 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 ->>> 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,13 +754,30 @@ 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 +>>>>> +>>>>>> That's actually excellent as the inline is a very useful feature +>>>>>> the way it works now. I started writing about this yesterday but +>>>>>> got interrupted. My indexes of albums use the inline in it's current +>>>>>> form. --k +>>>> >>>> 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 >>>> different captions depending on the context. In your example wiki with photos from gigs this would allow @@ -754,6 +795,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 @@ -784,3 +829,61 @@ to `doc/style.css` should be enough? --[[smcv]] > >> I searched for `/* relevant to the index page */` and found it twice, >> so I stand by what I said :-) --s +>> +>>> And right you are, unsure how I missed that. My album branch is now rebased +>>> on your album5 branch (with the two now useless commits removed). +>>> --[[cbaines]] + +cbaines, would you mind publishing an album with more realistic pixel-sizes +of images using your modified CSS? It's difficult to get an idea of how it +will degrade under conditions like "image size > browser window" with +images as small as the ones you used. You might find + +(`git clone git://git.pseudorandom.co.uk/git/smcv/ikiwiki-demos/ikialbum.git`), +or the same techniques, useful: it contains images with a realistic pixel +count, but very very lossy JPEG compression, to keep the size in bytes low. + +> I have now created a large (images) example, you can find all the examples +> here [1]. I have also built all the examples with the album5 branch, you can +> find the results here [2]. +> +> 1: +> 2: + +It's much, much easier to review changes if you use separate commits for +cosmetic changes like "separate index CSS from viewer CSS" and "more +consistent indentation", and functional changes like turning the prev/next +links from absolutely-positioned to floating. I'd be happy to apply +the cosmetic changes if they were in commits that were literally only +cosmetic changes, with no functional effect. + +> I have now rewritten the CSS changes to get a smaller diff. The only big +> functional change is from the previous patch is the max-width stuff to cope +> better with large images. + +For the functional bits: I think I'd have used floating boxes instead of the +absolutely-positioned boxes that are currently used if they provided the effect +I wanted. I can't remember exactly why I didn't do that now, but +it might have been because if the browser window shrinks below the image width, +floats have weird behaviour (they push the actual image out of the way), or because +I wanted the entire left/right margin of the image to be clickable to have +a large click-target for scrolling through the album. + +If there's something specific that you think is wrong with the CSS in my +branch, could you please explain it, and perhaps we can come up with something +that matches both our requirements? + +--smcv + +> I don't think that something specific is wrong with CSS in the album5 branch, +> but it does not display large [3], or small [4] images very well. It might be +> possible to resolve the image size issues without changing from absolute +> positioning, but I felt (for no particular reason) that I would do it using +> floats. +> +> The clickable region on the margin seems the most likely reason to me to go +> with absolute positioning, as an initial look at doing this with floats +> suggests that it is non-trivial. +> +> 3: +> 4: