https://bugs.kde.org/show_bug.cgi?id=385622
Holger <h.kl...@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |h.kl...@gmx.de
--- Comment #6 from Holger <h.kl...@gmx.de> ---
I don't dread multiple navigation routes so much: Okular also offers a history
of document locations, especially to undo clicks on hyperlinks within a PDF. In
addition it has an ordinary page-based forward/backward (using exactly the same
icons: lowerthan/greaterthan). Finally there is a third navigation route by the
search-util going to the next/previous result using up/down triangels for
symbols.
In gwenview the lowerthan/greaterthan icon is already associated with
next/previous pic in folder. So a history might use real arrows like Firefox
does with a third arrow-line meeting the other two at the tip.
But this is about it what you could learn from a Browser, as it is optimized
for a tabbed interface, whereas I don't want gwenview to discard all
forward-history just because you clicked another pic.
Also a browser does not distinguish files and folders. For Gwenview it might be
viable to offer separate go-to-(previous/-next)-folder actions.
>From this I'd derive the following requirements:
- the history is a single sequential list of image-file- & folder-locations
- no duplicate locations allowed (Set) navigating to the same file again just
pushes it to the top of the list
- each entry is tagged with a last-access time (to be updated on access),
sorted descending by this time-stamp
- going back or forth through the history by button / selecting an entry from
the start-page won't update the time-stamp and thereby the position in the
queue
- a folder-entry should also conserve the selection within that folder
- a move/rename operation should also update the corresponding history entry
- hitting a non-existant entry (e.g. deleted) should optionally remove the
history entry and move on to the next
- the list could be cleared on exit or be preserved as the start-page already
does now.
- there should be a resonable upper limit of e.g. 50 items in the list,
replacing the oldest item on opening a new one
If the list integrates tightly with the startpage anyway, it might also cache a
thumbnail-preview of each item, so it may even display deleted items with a
message, that the source no longer exists.
--
You are receiving this mail because:
You are watching all bug changes.
