ProjectMirador / mirador

An open-source, web-based 'multi-up' viewer that supports zoom-pan-rotate functionality, ability to display/compare simple images, and images with annotations.
https://projectmirador.org
Apache License 2.0
548 stars 258 forks source link

add / remove canvases on-the-fly without losing configured view data #706

Closed beaudet closed 4 years ago

beaudet commented 8 years ago

One of the ConservationSpace requirements is the ability to add and remove images from a single manifest. One way this could happen is to retrieve the manifest for a slot, modify the manifest externally, then cause Mirador to re-read it. If Mirador is able to embed view information into an exported manifest as requested in https://github.com/IIIF/mirador/issues/703, then Mirador could simply be re-initialized without losing any user view configurations that had been established prior to adding or deleting a canvas.

In addition to the above approach which requires a lot of processing, it should also be possible to provide Mirador methods for adding and removing a canvas from a slot's manifest on-the-fly. In this way, a manifest could grow and shrink without having to reload Mirador with the new, modified, manifest.

ConservationSpace users will add image canvases into Mirador via the (+) icon (see https://github.com/IIIF/mirador/issues/705) and by using the slot menu with a new "add images" menu option as requested in https://github.com/IIIF/mirador/issues/704. These features will invoke a custom ConservationSpace image search dialog. When an image is added to the ConservationSpace Image Widget, a canvas for this image will be appended to the manifest for that image widget and Mirador will need to update to display the new canvas.

https://github.com/IIIF/mirador/issues/490 is potentially related.

aeschylus commented 8 years ago

https://github.com/IIIF/manifesto https://github.com/UniversalViewer/manifesto

We need a comprehensive client library that provides a dynamic object and event interface for Presentation API data. In a waterfall development world, that probably would have been the first thing written. Such a library will make this automatic, presuming that the rendering code is written in a somewhat functional/reactive/declarative manner.

beaudet commented 8 years ago

Are you suggesting as an implementation approach that Mirador be retrofitted to use manifesto?

rsinghal commented 8 years ago

There is a strong argument against making Mirador do too much, such as manifest editing. I fear that Mirador will become too bloated and impossible for anyone to use. I very much like the idea of adding functionality to allow a user to refresh a manifest and preserving the view state for that manifest in Mirador on reload. If we consider Mirador the dumb viewer, this manifest editor could be a plug in that can work with Mirador but does not have any impact on Mirador's "dumb-ness."

beaudet commented 8 years ago

A module / plug-in to allow manifest editing seems like a good compromise and would reduce the footprint as well as the default complexity of the tool.

camillevilla commented 4 years ago

This ticket is being closed as part of the Mirador 3 issues review. We encourage all Mirador 2 implementers to try out Mirador 3 and leave feedback in new tickets.