Consider additional cases:
- flag got reset when deleting and adding first waypoint
- don't show empty on load, postpone to update
- don't store state when hidden because empty
Loading a track as route with lots of waypoints (simplify tolerance of 0) caused a long pause before even handling the first route request.
This seems to be caused by a repaint for every added marker/layer. Adding them all at once in FeatureGroup.addTo(map) helps (although still added in a loop).
Using i18next's "nesting" and "interpolation" features should reduce the
overall number of strings to translate, as well as provide a
standardized pattern for shortcut tooltips (if applicable).
Note that this approach is still allowing for flexibility regarding
differently structured sentences in each language.
Resolves#315
Often users can remember what the recently opened tab was, so we can
switch to and open the next tab immediately, saving one keypress. There
is a dedicated shortcut (T) for only opening a tab, after all.
While the previous behavior for Shift+T (open tab without switching to
next if currently closed) was by intention, user testing found that the
new approach might be more desirable.
The 'T' key will show/hide the most recent sidebar tab.
Pressing 'Shift+T' will switch to the next sidebar tab, possibly
wrapping around to the first tab.
If the Itinerary tab is hidden, it will be skipped.
Press 'S' to show the Strava buttons (if the API key has been set) as
well as the Strava segments layer (once it has been fetched).
Note that fetching and updating data from Strava still needs to be
triggered manually by clicking the respective biking or running button.
Press 'F', type a query and press 'Enter' to find places effortlessly.
Note that the button already triggers on mousedown events, even though
by convention it should react on mouseup (i.e. a regular click)
only. However, that's an issue in the external dependency, and can
be worked around for now.
The mute shortcut would only work for regular routes before.
Note that no-go areas, POIs and tracks continue to be unaffected
by muting, so e.g. peeking at a track below the route is still possible.
Do not allow browser keyboard shortcuts to trigger route functions,
e.g. pressing Ctrl+P triggers printing in most browsers, but should not
at the same time switch BRouter-Web to POI mode. This can be prevented
by filtering for modifiers.
In the same fashion, when modal dialogs or dropdowns are open it should
not be possible to activate map functions in the background now.
Finally, inhibit shortcuts in number input fields too, as found in the
editable number input fields in the customize profile options.
Previously only regular text input fields were protected.
To make those checks easier to use, they are deduplicated and moved to
Util.js.
Contrary to mouse clicks, when pressing keys on a keyboard the
standard behavior is to perform the associated action immediately,
not only when releasing the key again. This should also improve the
perceived performance slightly.
Note that the 'D' shortcut had formerly been handled by Leaflet, which
we now have to do on our own.
While at it, move the character codes over to the options variable, as
found in other parts of the codebase already.
Also removing the listener from the container does not seem needed
anymore nowadays.
Colorful routes can conflict visually with colourful maps, therefore
having an outline to make the route stand out more makes sense.
However, using black results in very high contrast levels, which can
become distracting in itself. By using a dark gray, this should look
much more balanced, while still fulfilling the original purpose.
Currently it is a bit difficult to guess the slope of the route for
planning purposes, since even for routes in very hilly terrain the
colors hardly change. Only extremely steep hills are indicated,
and there is no visual difference between going uphill or downhill.
By cutting off earlier, more of the route will show meaningful
differences in color. Note that BRouter's gradients are already
averaged compared to the maximum gradients shown on road signs, so 15%
should be a good compromise (anything steeper is difficult to ride on
for longer periods anyway, and rightly deserves to be colored with an
alarming red).
By using different colors for the min and max parameters, uphill and
downhill sections should now be easy to distinguish.
By introducing two more color stops, the gradient becomes much smoother,
with flat sections featuring a distinctive green, where they were drawn
in a muddy dark green before.
Note that this approach had been implemented like this in QLandkarte GT
for several years now, with great success.
- make icons a bit smaller
- also results in better vertical centering
- round icon too small for 3 digits, multiply width by digits
- increase opacity a bit for better readability
- with var instead of const all callbacks referenced last value in loop,
add closure
- cloning by property overwrites default when undefined, use L.extend
for Object.assign
