GNOME Bugzilla – Bug 169903
History / back button
Last modified: 2013-11-19 19:09:59 UTC
I would love to have a history feature like in web browser, with the ability to go back to the page I was before I click on a link or in the index.
Same deal as in Bug 169902 Adding features based on users wishing for a feature is the best path towards bloat. Adding features that solve problems users are having is the way to creating simple yet elegant programs.
Well, the situation is like for bug 169902. Browsing through a very big document, I sometimes need to go somewhere else in the document, to find more information about someting I'm currently reading, then go back to continue where I was before.
*** Bug 302892 has been marked as a duplicate of this bug. ***
Ok, so why would I like to have that feature: - For reference documents where I am browsing through the document searching for some information, I often jump from section to section (following a link which is pointing to additional information in the same document) and then coming back to the previous original section reading on. This is especially useful when reading the table ob contents. - For normal scientific papers sections or references are often linked. I click on them look what is there and want to go back. So much about the usage pattern. However such documents do not happen *very* often (like .pdf documents with index).
*** Bug 304970 has been marked as a duplicate of this bug. ***
*** Bug 308330 has been marked as a duplicate of this bug. ***
*** Bug 309059 has been marked as a duplicate of this bug. ***
Let's not make the same mistake as in web browsers; there should be some way of recording a history of viewed pages and it should be possible to create bookmarks, which would be nothing but persistant history items.
Working on a system with jrb, will give more details soon.
The current page back and forward button in the toolbar could be replaced by the ones proposed. I think people intend do not use the current page back and page forward button much but use the PageUp/PageDown of the keyboard or the scroll wheel or the scroll button. Furthermore people are used the back and forward behaviour of browsers.
Apparently back/forward based history navigation isn't the best, see Epiphany bug 161872 for a nice idea.
I would say that the technology used for back/forward would be bug for it self. Temporal Logic that is suggested on bug 161872 is still a back/forward button. This bug it about Previous/Next and Back/Forward.
*** Bug 321772 has been marked as a duplicate of this bug. ***
Sorry guys, but imho this is an essential feature and I wonder why evince hasn't implemented it already. gpdf had back/forward, previous/next and first/next features. Wouldn't it be possible to implement that into the next release of evince?
Sorry Pablo, this feature requires a lot of work and won't go into the next release. Before writing patch anyhow there should be consistent proposal about that, just Forward/Back is certainly unacceptable. The help on reworking such proposal would be greatly appreciated.
*** Bug 333191 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Working on a system with jrb, will give more details soon. > Any updates? The ability to hit Alt+Left Arrow to go back would be very welcome. Note that I'm only talking about going back when you "jump" through an internal link of the document. Regular scrolling, I guess, is much harder to handle in a back/forward system and would probably require a bookmark system or maybe automatically record a page the user has been seeing without scrolling for the last N seconds (large N).
Created attachment 66457 [details] evince 'jump' pages Sorry for such a delay. This was the old mockup I had for this design. The idea here is to show that we don't intend to give < back and forward > buttons which seem to really confuse the navigation system we have of page up / down. What we're intending to do here is allow people to click a link that jumps them somewhere (deeper) in the document. After they've been jumped to a new location we insert the 'jump' bar that shows them where they came from and where they are. A person could continue to jump around pages [1] within this 'history' and eventually go back to the original. Interaction is similar to the way the file chooser bar works which is why I used that widget to show this. Since this is just a mockup prototype using the same widget isn't necessary. [1] In testing on paper it looks like there will be a need for hiding or closing this bar. At the same time it might be advantageous to hide and reshow it in the same state it was left in. When someone goes back to the original page we don't want to hide this right away and we especially don't want to clear the 'history' right away. It seems natural to leave the bar around until the person navigates away in a different method. When we hide this bar it would have to retain it's state information in a similar way to the epiphany or firefox find bar. Such that you could navigate away from the origin page, but then go back to going through that history set. Of course this brings in the need for showing the bar in some non-automatic way like assigning a key code to bring it up. While not opposed to that, I don't think it's an ideal plan.
Just want to add that people should continue to iterate on ideas for a solution to this. I'm not completely sold on this mockup itself, however I think it's heading in the right direction. Talk on the mailing list, attach ideas here and come up with something new!
Just want to note that this feature is critical, the continued lack of it after a year and a half is completely embarrassing, the design mockup is terrible (people already know and expect the browser Back/Forward design and consistently placed buttons are handy from a muscle memory perspective), and kpdf already works today (I switched after some genius made "Previous Page" and "Next Page" in Evince require Ctrl in addition to PageUp and PageDown, plus the fact that Evince can't open PDF files without a .pdf extension was also extremely irritating).
Nicholas, unconstructive comments really don't help getting the fix of this bug any closer. Would it be crazy to "overload" the Previous button to not mean "pagenumber-1" per se, but _really_ the "previous page", so also the one you were viewing before you clicked a hyperlink? It may reduce the predictability of the Previous/Next button behaviour a bit, but that could be offset by the much increased "do what I mean" factor.
Hmmm... I was about to report another "bug" of the same sort. The use-case is that I'm reading scanned documents which have no index, and make backward references quite often ; this means that I have to check the number of the page I'm currently reading, and go backward until I find said reference, then use my brain-stored bookmark to go forth again. Would it be possible to have some sort of bookmark (not stored in the document) which would make this less painful ? (Well, the best would probably be writing the index as I read, but that looks harder) Most of the documents are djvu, others are pdf, and some are ps, if that counts.
(In reply to comment #20) > the design mockup is terrible > (people already know and expect the browser Back/Forward design and > consistently placed buttons are handy from a muscle memory perspective) So the issue here isn't being consitent with a certain type of button or widget people have seen, but providing a mechanism that works correctly with the types of documents you see through evince. The back/forward buttons on web browsers work great for going from one location to the next because it's easy to understand that. Similarly if you were walking in a mall and stopped at one shop, then went back to it later. Obviously the difference here is that you're not going back/forward in locations as much at changing area with in a single location (the viewed document). While you could argue that you're changing 'locations' with in the document the argument doesn't hold because it's the difference that people percieve that matters. When you travel from one web site to another there is an obvious change that takes place, jumping within a page on a document isn't as dramatic a change. Several examples of this problem creap up in different interfaces. You can see this with HTML anchors and how they confuse people using a browser. They clicked on a link which took them to a new area in the document they were viewing. Then when they click the back button they are still at the same document and are often confused by this. The back button usually brings them to the last document they were looking at, however the anchor link changes that and in usability tests you can see people are confused by this alternate behavior created in the back button. Unless you understand the technology behind it all, there doesn't seem to be an obvious reason. Another example is when file browsers use both directory up and back/forward buttons. This mix of buttons requires you to keep the history stack of changes in your own head in order to know where the back button will take you. Sure it's obvious that it will take you where you just were, but before that? You could have jumped up and down directories so your back history jumps around a bit without taking you some place useful. Anyway. After watching a number of people use internal links in PDF documents and use PDFs for refernces I'd gotten the sense that what might work best is just a rolling history. Not a back / forward button, but a history that just showed you what pages you looked at, maybe what pages you've looked at most. I haven't had much time to work on the details, but that's what the original mockup was working towards. The pager used in the file chooser gives you a back / forward history context with out the ambiguous back / forward buttons. By just showing the locations you can make a much better decision about where you'd like to get back to. There still requires lots of thought about how this works into the interface and how you use it. So if anyone likes this train of thought I'd love to see (a little less flak and ;) someone run with the ideas in that direction. Catch me on IRC or email.
*** Bug 354011 has been marked as a duplicate of this bug. ***
There is another mockup attached to bug 354011 which is similar to the one proposed by Bryan here.
Hi! I think the back-forward button is very difficult to implement, you need to create a entire history system(!) and fix all the bugs that brings all the possibilities(!!!!!).This is going to take a lot of time, and once finished, selected approach could be too complex and don't work. In an Internet brownser it works because pages are different documents, but using it for the same documment doesn't make sense to me.You need to add a complete set of commands that break evince simplicity. I love tab brownsing because is so simple, and fast, you see what you want, and click. I consider it relatively easy to implement because you only use pre-made components tabs, and the information you need to store is very simple.It could be done in a single day: -Someone makes a new tab: e.g File->save as tab. -The program only stores the page number. e.g in a list and binds it to a tab ID. -Program creates a new tab, and puts in it "_(Page) $number" -Program creates an event in tab, when clicked update the screen with page number.The code is already done with the numeric text entrie. Further complexities could be added later,like changing the tab name if desired, or adding a colored square icon so you can remember the "color" of the page you saved, or drag an drop support. I have done something like this is in a program I made, and believe me, is a revolutionary change for navigating digital documents. It breaks the mental barrier of navigating digital documents.(mind knows it is a lot of effort rigth now).
Came to bugzilla to report the same feature request. ALT+left would be extremely useful for the use cases already mentioned. It really solves a great problem. Right now we are using acroread because of this missing feature in Evince. Both the mockup and changing back-button are great; as long as it gets done. It's not possible to use Evince for reading big (1000 page) documents at this stage. A "hidden" key-binding (ALT+left) would do the trick for most of the powerusers while a more friendly method is being developed.
Another vote for this feature. When I follow a hyperlink in a pdf, I would like to be able to get back to the source of the link without having to find it again manually.
There's preliminary (not yet finished) support in CVS.
I experience something weird when I select go to previous page after follwing a link from the table of contents with hyperlinked destinations. Let's take the following document: http://ousia.iespana.es/pdf/tesis.utf8.pdf. Click on any link on pages 9-10 and go to the previous or next page pressing Ctrl+PgUp or Ctrl+PgDown. It goes to page 8 or 11, instead of the right previous or next page. This happens with evince-0.7.0 and it only happens when evince goes to previous or next page right after the link is followed. I hope my description is clear and it helps to fix the bug. Congratulations for your excellent work, Pablo
What I discovered (and I didn't realized before) is that evince doesn't switch the page number after an internal link has been clicked. Page number after pressing a link is not the link destination, but the link origin. I'm afraid that it is a bug. Thanks for your work, Pablo
*** Bug 412612 has been marked as a duplicate of this bug. ***
Any chance of this being worked on for the next release?
Ghee, it's already in 0.7.2, what's the problem?
Nickolay, COOL! Didn't know that it is in 0.7.2 already :) Since this bug doesn't show it is fixed, may be time to update bugzilla :) Thanks for letting know. Now it is time to try out 0.7.2.
I finally found the Back button in the toolbar (I'm using evince-0.8.0). I would suggest two improvements. It would be very useful to have a Forward button also and to have shortcuts for both Back and Forward (Alt+Back and Alt+Forward would be fine [or Ctrl instead of Alt]). Nickolay, thanks for your excellent work.
See http://mail.gnome.org/archives/evince-list/2008-July/msg00003.html
I'd like multiple bookmarks/notes - as a vi user I quite like the idea of them being identified by a letter or number and being able to jump to mark 'a' with a couple of keystrokes. My most often case of wanting to do this is to get back to an index to in a big document or back to a particular chapter. I don't need the ability to save them.
*** Bug 587942 has been marked as a duplicate of this bug. ***
*** Bug 588846 has been marked as a duplicate of this bug. ***
After reading this thread, I found the "Back" button I never realized Evince had. Would it be possible to keep the location within a page that one was at when a link was clicked? (Also, it looks like the location information about the link's destination is also lost when copied into the Back menu). To reproduce: 1) Open any scientific paper that links equations and bibliography entries. e.g. http://arxiv.org/pdf/0912.1027 (random new paper on arxiv.org) 2) Scroll down a bit and click on a number in parentheses to jump to the referenced equation. 3) Scroll to another page. 4a) Select the equation's page from the "Back" dropdown. 5a) Instead of jumping to the equation itself, the top of the page is selected. Alternatively, 4b) Select the page at the top of the Back list to return to where you were before clicking the link in step (2). 5b) The top of the page you were on is selected The result of (5a) seems like a definite bug. In ev_window_add_history(), if a link is passed in, a new EvLink is created with supposedly the same action. So, this seems like it would imply the same location (which is part of EvLinkDest inside the EvLinkAction). Changing the result of (5b) is a feature request. For me, the primary need for "back" functionality is to return to the one place I was before clicking a link (I want to glance at the equation / reference being referred to, and then continue reading). The rest of the history stack is much less important. Anyway, other than the fact that I have to search to find where on the page I was before clicking the link, this functionality has existed for almost 3 years without me finding it (and apparently many others given the duplicate bugs). So, Shouldn't the status of this bug be something other than "NEW"? Maybe also put something in the "Go" menu instead of just burying it inside the toolbar config?
After this comment, I looked harder for the back button, and after a while, indeed, here is how you get it: Right-click on the toolbar and select „Toobar“. There you find a „Back“ button that you can drag onto the toolbar. Here, the Back button actually has the same icon as the page down button, which seems to be a bug. Other than that, I think this bug can be closed, right?
thanks very much for implementing this feature. I was delighted to find the "Back" button in the toolbar, however, since I don't use the toolbar (I have it hidden by default to optimize viewing area), I wonder if there was a keystroke to it too? Several people here recommended [Alt]+[left] (similar to a popular web browser). For me at least, that doesn't seem to work. And I don't find anything in the documentation. May I also propose vim-style jumps: "o" jump back, "i" jump forward. Useful "vimitations" (h,j,k,l) do exist already! Oh and are you aware of Vimperators nice follow ("f") option? But I admit, that's a bit overshoot... :) Thank you for considering the needs of keyboard users.
As Sebastian, I wonder if there is a way to attach a keyboard shortcut to that back button.
Created attachment 165211 [details] [review] patch to add support for page history back/forward travelling The current Back Icon History is not so handy at least for me. Because it only record internal link or indexing page change, but what I need is as in other reader's. So I write a simple patch to add history travelling which behavior like other readers have had. It use a ring buffer(hardcoded max 128 entry) to manage history pages, and I had add 2 shortcut: * Ctrl+V for Forward, and * Ctrl+B for Backward (I want to use the Ctrl+F for Forward, but it already used to finding.) How about it?
Review of attachment 165211 [details] [review]: Thanks for the patch, but you are duplicating the history feature instead of fixing the current one. Take a look at shell/ev-history.c that is used in ev-window.c. Also, history should be entirely in the shell, not in libview.
Yes, you are right, we should enhance the current one. But it seems it's not an easy job to be done, from the history of this history things, I thinks. Always, this is a basic feature we should support, else we'll lost in the world. So I will think it more deeply.
Created attachment 165324 [details] [review] patch to add support for page history back/forward travelling(v2) I had reconstruct my history traveling patch, now move all codes under shell/ , and the code looks more cleaner. The shortcut key had changed to: * <alt><shift>Left for backward * <alt><shift>Right for forward I think this history travelling feature is a complement to current "Back" history. Should I rename the ev-page-history, or should I plug it into ev-history? But I really think they are two things.
This should be merged into our current history implementation, why are they two things?
Created attachment 165962 [details] [review] patch to add support for page history back/forward travelling(v3) Because my added page history is just gave the same behavior as other reader had gave us, and it's so stupid! But the current history is smart! As you suggested, I had put a ev-page-history instance in ev-history, and add some wrapper api to access it.
I still don't see the point, with your patch we have two different ways of doing the same thing, the olod one using the toolbar button and the new one with new menu entries.
ok, let it be. sorry for my later!
bug 424833 seems to be a duplicate…
*** Bug 424833 has been marked as a duplicate of this bug. ***
I wish I found this feature sooner! Which brings me to my my first issue with the implementation: (1) the navigation history feature is not discoverable. It is the only toolbar button that does not have a corresponding menu entry and the toolbar button is not even enabled by default. I suggest enabling it by default and adding something under the Go menu like: Go -------- Previous Page Next Page -------- First Page Last Page -------- Back -> Last Location Alt+Left Last Location - 1 Last Location - 2 (2) the icon should be the standard GNOME back icon (left-pointing arrow) (3) a key binding should exist (the de facto standard being Alt+Left and Alt+Right) Thanks!
(In reply to comment #55) > I wish I found this feature sooner! Which brings me to my my first issue with > the implementation: > > (1) the navigation history feature is not discoverable. It is the only toolbar > button that does not have a corresponding menu entry and the toolbar button is > not even enabled by default. I suggest enabling it by default and adding > something under the Go menu like: > > Go > -------- > Previous Page > Next Page > -------- > First Page > Last Page > -------- > Back -> Last Location Alt+Left > Last Location - 1 > Last Location - 2 > > (2) the icon should be the standard GNOME back icon (left-pointing arrow) > > (3) a key binding should exist (the de facto standard being Alt+Left and > Alt+Right) > > Thanks! Yeah, we haven´t update evince UI in a long time, so we are discussing now how to improve the UI and I think we are adding something very similar to what you are proposing here. One more improvement, the back button should be more like in Firefox where if you click once, you don t get the menu, but go directly to the last page visited. If you click longer, or in the expander, then you get a menu of the page visited. Will upload mockups so we can get UI review from the Design team
I made this mockup a long time ago when we started to discuss how to improve the history UI. http://carlosgc.linups.org/files/ev-history.png See bug #554585
Epiphany has a nice GTK+-only implementation for this type of toolbar button+drop down. Perhaps it can be reused?
(In reply to comment #58) > Epiphany has a nice GTK+-only implementation for this type of toolbar > button+drop down. Perhaps it can be reused? Note that Nautilus 3.0 uses a Firefox-like click-and-hold dropdown menu on the back button. Not that I think it's necessarily a better approach though...
I've finally added classical back/forward buttons to the new toolbar similar to the ephy and nautilus ones. Please, open new bug reports for any issues you find with the new history buttons.
*** Bug 607326 has been marked as a duplicate of this bug. ***