Bug 385622 - Please add Back Button to Gwenview
Summary: Please add Back Button to Gwenview
Status: CONFIRMED
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 16.12.3
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2017-10-11 17:56 UTC by Bobby
Modified: 2020-12-29 17:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot of what happens anytime I use gwenview on anything more complicated than a folder of images (33.27 KB, image/png)
2017-10-11 17:56 UTC, Bobby
Details
current histroy (86.80 KB, image/png)
2020-12-29 17:26 UTC, Holger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bobby 2017-10-11 17:56:41 UTC
Created attachment 108285 [details]
Screenshot of what happens anytime I use gwenview on anything more complicated than a folder of images

Please please add the back button as an optional toolbar button to gwenview.  The Up arrow and the back button ARE NOT the same thing and I run into constant frustration as I click on an archive, view an image, click up to "go back", and get an error message because some file handler (i.e. krarc://) cannot doesn't work on a file path that doesn't include the actual file it is supposed to handle.

The back button is not an up button, and there is no intuitive way to go "back" to where I just was with the current configuration.
Comment 1 Christoph Feck 2017-10-12 07:38:45 UTC
That is a bug in krarc: handler. It works correctly with the zip: handler, for example.

I suggest to report it separately to krusader developers.
Comment 2 Bobby 2017-10-13 15:46:49 UTC
Itsn't it a little insane to change every single handler has to be programmed to do the same thing as a back button... instead of just including a back button?  

Also, krusader HAS a back button.  Meaning the behavior is correct for if your wanting to go up instead of back inside of krusaders windows. It would dolphin trying to emulate the back behavior inside of the up behavior that is the problem.
Comment 3 Bobby 2017-10-13 15:49:51 UTC
Sorry, I mean it would be Gwenview trying to emulate the back button. Krusader has BOTH up and back buttons because they are not the same action.  

Is there a problem with including a back button?
Comment 4 Christoph Feck 2017-10-13 19:36:03 UTC
There is no problem in adding a 'Back' button. If you have a patch, we can review it.

All I said is that going up in krarc: is buggy, and if the bug was reported and fixed, you would not get constantly frustated.
Comment 5 null 2018-05-11 20:49:35 UTC
The issue with going up for krarc:/ is handled in Bug 386448.

Adding forward/backward navigation history to Gwenview also crosses my mind from time to time, but I'm undecided yet on how to best integrate this into the UI, as it could easily cause confusion with the previous/next image actions.
Comment 6 Holger 2019-03-04 19:44:26 UTC
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.
Comment 7 Holger 2020-12-29 17:26:40 UTC
Created attachment 134384 [details]
current histroy

Meanwhile Gwenview 19.12.3 comes with a "history menu" .. see screenshot.

Only it has some issues of handling folders if one picture is shown large:
- open image1 in folder1
- drop back to folder1 overview
- navigate to folder2 still in overview-mode
- open imgage2
- use the history to go back to image1 (it displays fine)
The error is one of:
- press escape to get back to the folder - now you are still in folder2
- try to navigate to next/previous picture before/after image1 but you instead get siblings of image2

It does not always happen, though I have a hard time reproducing a case where it correctly jumps back to folder1. For now, it is safer, to only use the history in folder-overview, where it will also navigate to the correct folder.

Oh and I could not find a way to go back to a multiselection / an arrangement of 2 or more pictures open at the same time.