The toolbar button does not address this bug. It does not manage pages as a stack. I think it is based upon some web-browser user interface work that displayed the title of recently visited pages in a drop down list, based upon when the page was viewed. This is a reasonable way to present a browser history.
However, under evince, the drop down menu often displays page numbers, since pages in pdf files do not have titles. Worse, the list is presented in a mysterious order. Surely, any user interface that requires the user to remember which page or chapter contained a previously clicked link is broken.
Regardless of whether the current evince behavior is "better" than standard web browser interfaces (see upstream bug), gnome should standardize on a single browsing paradigm, and Nautilus provides a reasonable user interface. However, nautilus provides a breadcrumb bar, and it's not clear that a breadcrumb bar would be useful with evince; in practice, it would contain a bunch of page numbers or section headings.
The current situation introduces a non-standard set of navigation primitives, and still (after 4 years) does not support alt-left. Also, using the mouse to navigate backwards in this UI is awkward. In the best case, following a link backwards requires two mouse clicks. However, after you have clicked a few links, you have to search for the link (page number) you want in an apparently randomized list.
There was some debate over the correct semantics for a back button upstream a few years ago. Xpdf only pushes things onto the stack when links are clicked; it does exactly what a web browser does. This seems like the right approach. Also, the debate over web browser back button user interfaces has evolved a bit since this bug was filed. Perhaps the current 'back' toolbar button could be replaced with one that clones firefox's interface.
The toolbar button does not address this bug. It does not manage pages as a stack. I think it is based upon some web-browser user interface work that displayed the title of recently visited pages in a drop down list, based upon when the page was viewed. This is a reasonable way to present a browser history.
However, under evince, the drop down menu often displays page numbers, since pages in pdf files do not have titles. Worse, the list is presented in a mysterious order. Surely, any user interface that requires the user to remember which page or chapter contained a previously clicked link is broken.
Regardless of whether the current evince behavior is "better" than standard web browser interfaces (see upstream bug), gnome should standardize on a single browsing paradigm, and Nautilus provides a reasonable user interface. However, nautilus provides a breadcrumb bar, and it's not clear that a breadcrumb bar would be useful with evince; in practice, it would contain a bunch of page numbers or section headings.
The current situation introduces a non-standard set of navigation primitives, and still (after 4 years) does not support alt-left. Also, using the mouse to navigate backwards in this UI is awkward. In the best case, following a link backwards requires two mouse clicks. However, after you have clicked a few links, you have to search for the link (page number) you want in an apparently randomized list.
There was some debate over the correct semantics for a back button upstream a few years ago. Xpdf only pushes things onto the stack when links are clicked; it does exactly what a web browser does. This seems like the right approach. Also, the debate over web browser back button user interfaces has evolved a bit since this bug was filed. Perhaps the current 'back' toolbar button could be replaced with one that clones firefox's interface.