openseadragon/openseadragon — pull request #46 by houseofyin (2013-03-17 01:46:07+00:00)
Title: Issue37 navigator

Folks,

I have taken a crack at the various suggested changes with the navigator. I would be interested in feedback on this candidate.

* A user can specify an id for a div to hold the navigator instead of letting Seadragon generate one. (The property is called navigatorId. The partial implementation that had been in place called it navigatorElement, but I changed the property name to better align with the id property used for the main viewer element property). There are some demo pages with various configurations. One targets a jQuery dialog. Another one just puts a plain div on the page.

* You can now either drag or click on the navigator. I thought about, but didn't implement an idea to try to keep the viewer anchored on the image itself. I would be interested in thoughts as to whether this would be a desired behavior. Similarly, for the click, I have anchored that on the top left of the view, but I can see a case for anchoring on the center. Any thoughts?

* The navigator no longer has an active state. If it is visible, it can be clicked or dragged. However, I turned off the auto-fade if the navigator is in a custom div.

* The navigator selected region is no-longer resizable.

* I move the keyboard operations to the main viewer. I don't quite like how this one feels yet. You still need to have focus on the main viewer for this to work. I can see some situations where it might make sense to just attach those events to the document instead to avoid the whole focus issue. However, I didn't spent too much time on this. I was beginning to worry that I was getting into too much code that was going to change when the updated to the event handler.

* There are some other internal changes. E.g. I changed the control constructor to take an options object instead of an anchor object. Since I was adding some new parameters about whether an element needed to be created and for something about the autofade, it seemed to make sense to go with the properties object instead of stringing along additional parameters.

* There was a comment in the navigator code about a magic number. I believe that number was being driven by the element padding and border. I made a fix to make that intent clearer.