Now we use the browser's native dblclick event on pointer
devices, and we fire dragstart and dragend only if we're really
dragging, and not on mousedown/touchstart and mouseup/touchend.
We don't register two listeners for mouseup and touchend any
more. And instead of using the native click event on touch
devices, we react on touchend, to make clicking more responsive.
On pointer devices, the underlying native event of a dblclick
event is now a click event.
This rather large commit refactors the build system to solve a number of
problems:
- Object literal types are now declared in just one place
- There are no more circular dependencies
- There is no need for concealed subclasses in build-standalone mode
When building in standalone mode, you need to include the source in
build/src/external. This declares object literal types as externs so
that their properties are not renamed.
When building with the application, you need to include the source in
build/src/internal. This declares object literal types as typedefs so
that their properties can be renamed and removed.
Note also that ol.MapOptions has been merged into ol.Map, with some
renaming.
ol.overlay.Overlay can be used to bind DOM elements to a
coordinate on the map. It has positioning options to support
e.g. popups or image markers that have an anchor at the bottom
and an unknown size.
The overlayContainer stops propagation on mousedown and
touchstart events, so clicks and gestures on overlays don't
trigger any MapBrowserEvent. To make this work reliably, we now
only fire dblclick in mapbrowserevent.js when there was a
previous mousedown or touchstart. The default container for
controls is now the overlayContainer.
Thanks @fredj for the inspiration. This gives us initial rotation support. It exposes some issues in the interactions that I'll address separately. Closes#22.
When zooming to a new zoom level, we can immediately remove tiles from the previous level. This (strongly) suggests not adding images to the container until they have actually loaded.
We only want to adjust things that have to do with rendering (like the position of the layers panel) when actually rendering. The handleXChange methods may be called more times than we can actually render, so we never want to do anything that touches the DOM there. Instead, we have to keep track of the state at previous render and adjust the layers panel (or other) based on changes only when rendering.
