diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/bugs/img_with_alt_has_extra_double_quote.mdwn | 30 | ||||
| -rw-r--r-- | doc/plugins/contrib/album.mdwn | 100 | ||||
| -rw-r--r-- | doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn | 12 | ||||
| -rw-r--r-- | doc/todo/wikitrails/discussion.mdwn | 61 | ||||
| -rw-r--r-- | doc/users/smcv/gallery.mdwn | 16 |
5 files changed, 214 insertions, 5 deletions
diff --git a/doc/bugs/img_with_alt_has_extra_double_quote.mdwn b/doc/bugs/img_with_alt_has_extra_double_quote.mdwn new file mode 100644 index 000000000..18aea6841 --- /dev/null +++ b/doc/bugs/img_with_alt_has_extra_double_quote.mdwn @@ -0,0 +1,30 @@ +The [[ikiwiki/directive/img]] directive emits an extra double quote if alt=x is +specified (as is necessary for valid HTML). This results in malformed HTML, +like this: + + <img src="U" width="W" height="H"" alt="A" /> + ^ + +This [[patch]] is available from the img-bugfix branch in my git repository: + + commit a648c439f3467571374daf597e9b3a659ea2008f + Author: Simon McVittie <smcv@ http://smcv.pseudorandom.co.uk/> + Date: 2009-06-16 17:15:06 +0100 + + img plugin: do not emit a redundant double-quote before alt attribute + + diff --git a/IkiWiki/Plugin/img.pm b/IkiWiki/Plugin/img.pm + index a697fea..a186abd 100644 + --- a/IkiWiki/Plugin/img.pm + +++ b/IkiWiki/Plugin/img.pm + @@ -121,7 +121,7 @@ sub preprocess (@) { + my $imgtag='<img src="'.$imgurl. + '" width="'.$im->Get("width"). + '" height="'.$im->Get("height").'"'. + - (exists $params{alt} ? '" alt="'.$params{alt}.'"' : ''). + + (exists $params{alt} ? ' alt="'.$params{alt}.'"' : ''). + (exists $params{title} ? ' title="'.$params{title}.'"' : ''). + (exists $params{class} ? ' class="'.$params{class}.'"' : ''). + (exists $params{id} ? ' id="'.$params{id}.'"' : ''). + +--[[smcv]] diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn new file mode 100644 index 000000000..94d5789d7 --- /dev/null +++ b/doc/plugins/contrib/album.mdwn @@ -0,0 +1,100 @@ +[[!template id=plugin name=album author="[[Simon_McVittie|smcv]]"]] +[[!tag type/chrome]] + +Available from [[smcv]]'s git repository, in the `album` branch +([[users/smcv/gallery|users/smcv/gallery]] contains some older +thoughts about this plugin). + +This plugin formats a collection of images into a photo album, +in the same way as many websites: good examples include the +PHP application [Gallery](http://gallery.menalto.com/), Flickr, +and Facebook's Photos "application". I've called it `album` +to distinguish it from [[contrib/gallery|plugins/contrib/gallery]], +although `gallery` might well be a better name for this functionality. + +The web UI I'm trying to achieve consists of one +[HTML page of thumbnails](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/) +as an entry point to the album, where each thumbnail links to +[a "viewer" HTML page](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/img_0068/) +with a full size image, next/previous thumbnail links, and +[[plugins/comments]]. + +(The Summer of Code [[plugins/contrib/gallery]] plugin does the +next/previous UI in Javascript using Lightbox, which means that +individual photos can't be bookmarked in a meaningful way, and +the best it can do as a fallback for non-Javascript browsers +is to provide a direct link to the image.) + +## Writing the viewers + + \[[!albumimage image=foo.jpg album=myalbum + title=... + caption=... + copyright=... + size=... + viewertemplate=... + ]] + +Each viewer contains one `\[[!albumimage]]` directive. This +sets the `image` filename, the `album` in which this image appears, +and an optional `caption`, and can override the `size` at which to +display the image and the `viewertemplate` to use to display the +image. + +It can also have `title`, `copyright` and `date` parameters, which +are short-cuts for [[ikiwiki/directive/meta]] directives. + +The viewer can also have any other content, but typically the +directive will be the only thing there. + +Eventually, there will be a specialized CGI user interface to +edit all the photos of an album at once, upload a new photo +(which will attach the photo but also write out a viewer page +for it), or mark an already-uploaded photo as a member of an +album (which is done by writing out a viewer page for it). + +The `\[[!albumimage]]` directive is replaced by an +[[ikiwiki/directive/img]], wrapped in some formatting using a +template (by default `albumviewer.tmpl`). The template can (and +should) also include "next photo", "previous photo" and +"up to gallery" links. + +The next/previous links are themselves implemented by +[[inlining|ikiwiki/directive/inline]] the next or previous +photo, using a special template (by default `albumnext.tmpl` +or `albumprev.tmpl`), in `archive`/`quick` mode. + +## Writing the album + +The album contains one `\[[!album]]` directive. It may also +contain any number of `\[[!albumsection]]` directives, for +example the demo album linked above could look like: + + \[[!album]] + <!-- replaced with one uncategorized photo --> + + ## Gamarra + + \[[!albumsection filter="link(gamarra)"]] + <!-- all the Gamarra photos --> + + ## Smokescreen + + \[[!albumsection filter="link(smokescreen)"]] + <!-- all the Smokescreen photos --> + + ... + +The `\[[!album]]` directive is replaced by an +[[ikiwiki/directive/inline]] which automatically includes every +page that has an `\[[!albumimage]]` directive linking it to this +album, except those that will appear in an `\[[!albumsection]]`. + +The `inline` is in `archive`/`quick` mode, but includes some +extra information about the images, including file size and a +thumbnail (again, made using [[ikiwiki/directive/img]]). The +default template is `albumitem.tmpl`, which takes advantage +of these things. + +Each `\[[!albumsection]]` is replaced by a similar inline, which +selects a subset of the photos in the album. diff --git a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn new file mode 100644 index 000000000..fc575e013 --- /dev/null +++ b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn @@ -0,0 +1,12 @@ +A [[patch]] in my git repository (the inline-pagenames branch) adds the following +parameter to the [[ikiwiki/directive/inline]] directive: + +> * `pagenames` - If given instead of `pages`, this is interpreted as a +> space-separated list of links to pages (with the same +> [[ikiwiki/SubPage/LinkingRules]] as in a [[ikiwiki/WikiLink]]), and they are inlined +> in exactly the order given: the `sort` and `pages` parameters cannot be used +> in conjunction with this one. + +This is on my [[wishlist]] for my [[plugins/contrib/album]] plugin, which currently +uses it internally (as it has already collected the pages in order). It could also +be useful for other things, like [[todo/wikitrails]]. --[[smcv]] diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn index 327e61491..b2a0937ad 100644 --- a/doc/todo/wikitrails/discussion.mdwn +++ b/doc/todo/wikitrails/discussion.mdwn @@ -4,6 +4,8 @@ one-photo-per-page galleries, where each page has previous|up|next links (\[[!inline]] with a specially modified template perhaps). I'll watch this with interest! --[[smcv]] +---- + This is a nice idea, I do have my gripes about the imeplementation. Assuming that the index's list is in mdwn format is not ideal. I guess the @@ -22,3 +24,62 @@ breadcrums to be automatically inserted at the top of every page on the trail. (You'd have to use a directive to define the index for that to work.) --[[Joey]] + +---- + +Revisiting this, after effectively reimplementing a small version of it +in [[plugins/contrib/album]]: it occurs to me that might be a more +"ikiwiki-like" way we could get this functionality. + +In the index page, you either want an [[ikiwiki/directive/inline]], or +a list of links. In the former case, maybe we could extend inline like +this: + + \[[!inline ... blah blah ... trail=yes]] + +to make it remember the pages it inlined, in order, in the pagestate; +in the latter case, we could replace the wikilinks with a directive, +an operation something like this in diff notation: + + - \[[one]] - the unit + - \[[two]] - the base of binary + - \[[three|3]] - is a crowd + + \[[!trailitem one]] - the unit + + \[[!trailitem two]] - the base of binary + + \[[!trailitem three|3]] - is a crowd + +and have that directive remember the pages in order. + +In both cases, a scan() hook could clear the list before starting to +scan, then the inline or trailitem preprocessor directive could run in +the scan stage as well as the render stage (in the case of inline, +there'd be a very early return if trail=yes was not given, and +an early return after collecting and sorting the pages if not +actually rendering). + +This would mean that the contents of the trail, and a list of +trails in which each page can be found, would already be in +the pagestate by the time any page was rendered, so we'd be able +to use them for output, either in a pagetemplate() hook or +a \[[!trail]] preprocessor directive. + +This way, my album plugin could be turned inside out: instead +of precomputing the pages to be inlined, then using +[[pagenames|todo/inline plugin: specifying ordered page names]] +to get them into the inline, it could just do the inline, then +incorporate the output of \[[!trail]] into the template rendered +for \[[!albumimage]] on each viewer page. (Also, the viewers +wouldn't necessarily need to reference the album, only the other +way round.) + +Using a pagetemplate() hook to stuff the next/previous links +into page.tmpl would actually be a bit unfortunate for \[[!album]], +because that plugin definitely wants to style the next/previous +links as a thumbnail, which means there'd have to be a way to +affect the style - perhaps by arranging for album's pagetemplate +hook to run *after* trail's, or perhaps by having trail's +pagetemplate hook disable itself for pages that contain +a \[[!trail]] directive. + +Does this sound viable? Should I think about implementing it? +--[[smcv]] diff --git a/doc/users/smcv/gallery.mdwn b/doc/users/smcv/gallery.mdwn index b6b8de79f..d80fc3ba1 100644 --- a/doc/users/smcv/gallery.mdwn +++ b/doc/users/smcv/gallery.mdwn @@ -1,8 +1,5 @@ -[[!template id=plugin name=smcvgallery author="[[Simon_McVittie|smcv]]"]] -[[!tag type/chrome]] - -This plugin has not yet been written; this page is an experiment in -design-by-documentation :-) +This plugin has now been implemented as [[plugins/contrib/album]]; this +page has older thoughts about it. ## Requirements @@ -124,6 +121,8 @@ an option!) ### Synthesize source pages for viewers +(Edited to add: this is what [[plugins/contrib/album]] implements. --[[smcv]]) + Another is to synthesize source pages for the viewers. This means they can have tags and metadata, but trying to arrange for them to be scanned etc. correctly without needing another refresh run is somewhat terrifying. @@ -145,6 +144,10 @@ in that directory during the refresh hook. The source pages could be in the underlay until they are edited (e.g. tagged), at which point they would be copied into the source-code-controlled version in the usual way. +> Coming back to this: a specialized web UI to mark attachments as part of +> the gallery would make this easy too - you'd put the photos in the +> underlay, then go to the CGI and say "add all". --[[smcv]] + The synthetic source pages can be very simple, using the same trick as my [[plugins/comments]] plugin (a dedicated [[directive|ikiwiki/directives]] encapsulating everything the plugin needs). If the plugin automatically @@ -153,6 +156,9 @@ only the human-edited information and a filename reference need to be present in the source page; with some clever lookup rules based on the filename of the source page, not even the photo's filename is necessarily needed. +> Coming back to this later: the clever lookup rules make dependency tracking +> hard, though. --[[smcv]] + \[[!meta title="..."]] \[[!meta date="..."]] \[[!meta copyright="..."]] |