* Refactor `TouchHandler` to handle double-tap and swipe gestures.
* Renamed existing `onTouch` JavaScript methods to `onItemTouch` and
added `onContentTouch` methods for swipe gesture.
* Refactor double-tap. It's now a method in `TouchHandler` versus
anonymous functions in `listen()` method.
* Updated CSS classes.
* Added `touch-action` CSS for `.entry-content`.
* Renamed CSS classes for adding events in `TouchHandler`.
* Updated users settings to replace checkbox for double tap with select
for none, double tap, or swipe.
* Added database migrations for new gesture_nav option.
* Rename `users.double_tap` to `users.gesture_nav` and migrate
existing user settings.
* Updated translation files. (Non-English updated with Google
Translate.)
Resolves#1449, closes#1495
Whenever the "prev" and "next" buttons have no hyperlink, decrease their
opacity to signal that they lead to nowhere.
This signal is stronger and more obvious than the current one which
merely removes the underline decoration from the text.
This patch is an improvement on top of
https://github.com/miniflux/v2/pull/1107
Currently there is "Toggle read/unread = m", which toggles and
then goes to the next item.
Having the opposite operation available is handy, especially when adding
new feeds and going through them from oldest to newest posts.
It seems natural to map 'M' (= shift + 'm') for this action.
Closes https://github.com/miniflux/v2/issues/1352
Enable users to move to prev/next page without having to scroll all the
way to the bottom of the page.
Furthermore, ensure consistency with entry.html which has top and bottom
pagination.
Why:
A user might want to unshare a specific entry. Navigating to the shared
entries page requires a mental context switch, whereas having the
ability right in the entry page makes it easier.
What:
Add an extra <li> element to display the unshare icon and link in the
entry view as well as the item_meta template. The latter is shared for
multiple pages listing entries, e.g. bookmarks, feed entries, search,
history etc.
The functionality already exists for the shared entries page, we are
just expose it in a couple more places
Signed-off-by: Alexandros Kosiaris <akosiaris@gmail.com>
Why:
It is nice to have the ability to mark an entire category as read in the
UI. The API already exposes that functionality anyway, so for
consistency reasons, expose it in the UI as well
What:
Add a new handler in the UI to markCategoryAsRead() and amend views and
router to expose the functionality in the UI
