GNOME Bugzilla – Bug 732289
Declutter the headerbar
Last modified: 2018-05-22 15:40:24 UTC
Created attachment 279332 [details] Screenshot of Documents showing the navigation buttons In #gnome-hackers there Matthias Clasen suggested to use the used in Document for navigating through the document. Here is the conversation, and attached is the screenshot (in case the it expires from imgr.com). <andreasn> https://lh3.googleusercontent.com/-lmEo5j2elRQ/U6w2uNDySSI/AAAAAAAAFnI/CVUmR_jPWhU/w1344-h757-no/evince+3133+normal+view.jpg <andreasn> so many buttons <andreasn> so little title <andreasn> but apart from that, nice to see headerbar support in Evince! <gpoo> that was one of the concerns <ebassi> the page selector should go in a popover <-- rodrigo has quit (Computer has gone to sleep.) <ebassi> what do the up/down/left/right buttons do? <gpoo> navigate through the document <mclasen> andreasn: they have all the arrows! <ebassi> then they should probably go there as well <andreasn> up+down is previos and next <andreasn> the back+forward is historical navigation <ebassi> previous/next what? page? <andreasn> yes, next page in the pdf document <ebassi> right <mclasen> could do the same floating arrows we do in documents for that <gpoo> mclasen: do you have a screenshot or something? <mclasen> gpoo: http://i.imgur.com/0Ix0B3n.png <gpoo> thanks <gpoo> are those always on screen? <gpoo> what does the left arrow in the left upper corner? <andreasn> on hover <aday> gpoo, yay for the header bar! losing the close button when maximised is a drag. i'd be happy to help you with this <mclasen> gpoo: in fullscreen they fade away and reappear on motion <andreasn> gpoo: arrow back in the headerbar is for navigating back to the library view <mclasen> in non-fullscreen, they seem to be permanent <mclasen> oh, not true <mclasen> they always fade away
Created attachment 279518 [details] Mockup What about something like this? I think we could add another section to the popover for the history navigation, and remove those buttons from the header bar too. The problem is that history buttons have a submenu, so I'm not sure how to represent that in the popover, we could make them submenu actions, but that would force you to always use the submenu to go backward/forward.
(In reply to comment #1) > Created an attachment (id=279518) [details] > Mockup > > What about something like this? ... I personally find it difficult to know what the buttons in that popover do. They imply horizontal navigation, yet the document is arranged vertically. Is it really necessary to have page up/down buttons? You can already scroll or use the keyboard for this. Likewise, document start/end can be easily navigated to using the text entry.
Created attachment 279692 [details] another mockup Something like this seems a lot cleaner and easier to understand.
(In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=279518) [details] [details] > > Mockup > > > > What about something like this? > ... > > I personally find it difficult to know what the buttons in that popover do. > They imply horizontal navigation, yet the document is arranged vertically. Yes, same happens with the overlay buttons in gnome-documents. > Is it really necessary to have page up/down buttons? You can already scroll or > use the keyboard for this. I've never used them, to be honest, because I always use the continuous mode. > Likewise, document start/end can be easily navigated > to using the text entry. Same here, those options are currently "hidden" in the gear menu.
(In reply to comment #3) > Created an attachment (id=279692) [details] > another mockup > > Something like this seems a lot cleaner and easier to understand. Thanks for the mockup, I think we might get rid of navigation buttons, but I don't think we can remove the history navigation
(In reply to comment #4) ... > > I personally find it difficult to know what the buttons in that popover do. > > They imply horizontal navigation, yet the document is arranged vertically. > > Yes, same happens with the overlay buttons in gnome-documents. ... Navigation in Documents is horizontal, not vertical - hence horizontal arrows work there.
(In reply to comment #6) > (In reply to comment #4) > ... > > > I personally find it difficult to know what the buttons in that popover do. > > > They imply horizontal navigation, yet the document is arranged vertically. > > > > Yes, same happens with the overlay buttons in gnome-documents. > ... > > Navigation in Documents is horizontal, not vertical - hence horizontal arrows > work there. Sure, I meant it doesn't work for us.
Created attachment 281605 [details] [review] Remove the Next-Page and Previous-Page buttons from the toolbar. Move the actions to the View menu. Also move the Last Page and First Page to the View menu.
Created attachment 281606 [details] [review] Remove unused ev_toolbar_create_button and ev_toolbar_create_button_group
Review of attachment 281605 [details] [review]: Ok, let's see how it works
Review of attachment 281606 [details] [review]: Ok, if we need them again we can just bring them back from history
Created attachment 282772 [details] screenshot I've attached a screenshot from master. The current header bar seems rather confusing. There are a bunch of things we can do to improve this, but there are two particularly serious issues that I think need to be addressed first: 1. The grid button is somewhat ambigous but, more than that, it is rather inconsistent with the multi-window model of Evince - the whole idea of which is one document per window. My suggestion here would be to only show the Recent Documents view when Evince is launched without a document being specified. The addition of a New Window option to the header bar menu would then allow access to Recent Documents, and the grid button would no longer be necessary. 2. The < > buttons are really confusing. They are only useful when you have skipped between parts of a document, and are often insensitive all the time. Browser buttons of this type are typically used to navigate between different atomic locations - like in a browser - not locations within a visible sequence. It isn't clear what < or > mean in this context. Since the back and forward buttons are only useful some of the time, it would be appropriate to only show them when they can be used - you could use an infobar, in-app notification, or floating control to show these controls when they are needed. This would also give you the opportunity to make them much clearer. For example: +---------------------------------------------------------+ | +------+---------+ | | Navigation History Page 4 | Back | Forward | X | | +------+---------+ | +---------------------------------------------------------+
(In reply to comment #12) > Created an attachment (id=282772) [details] > screenshot Hey Allan, thanks for your help with this. > I've attached a screenshot from master. The current header bar seems rather > confusing. There are a bunch of things we can do to improve this, but there are > two particularly serious issues that I think need to be addressed first: > > 1. The grid button is somewhat ambigous but, more than that, it is rather > inconsistent with the multi-window model of Evince - the whole idea of which is > one document per window. > > My suggestion here would be to only show the Recent Documents view when Evince > is launched without a document being specified. The addition of a New Window > option to the header bar menu would then allow access to Recent Documents, and > the grid button would no longer be necessary. I like the idea of moving the option to the app menu, it would also solve the problems of having to check if the selected document in the recent view is the current one or not, and would simplify all the complexity of the view mode switch. In most of the cases if you go to the recent view/menu is to open a new document. > 2. The < > buttons are really confusing. They are only useful when you have > skipped between parts of a document, and are often insensitive all the time. > Browser buttons of this type are typically used to navigate between different > atomic locations - like in a browser - not locations within a visible sequence. > It isn't clear what < or > mean in this context. > > Since the back and forward buttons are only useful some of the time, it would > be appropriate to only show them when they can be used - you could use an > infobar, in-app notification, or floating control to show these controls when > they are needed. This would also give you the opportunity to make them much > clearer. For example: > > +---------------------------------------------------------+ > | +------+---------+ | > | Navigation History Page 4 | Back | Forward | X | > | +------+---------+ | > +---------------------------------------------------------+ Something like my first mockup but with history buttons instead of navigation buttons?
Hey, thanks for the comments. I am implementing this, but then got stuck with the correct functionality for the following use case. Suppose you already have a document open, say "file1.pdf", and you open a new window from the App Menu, and then click again in "file1.pdf", which should be the correct behavior? With this, it makes sense to me that the intention of the user is to open a different copy of the file, but I am not sure.
(In reply to comment #14) > Hey, thanks for the comments. I am implementing this, but then got stuck with > the correct functionality for the following use case. Suppose you already have > a document open, say "file1.pdf", and you open a new window from the App Menu, > and then click again in "file1.pdf", which should be the correct behavior? With > this, it makes sense to me that the intention of the user is to open a > different copy of the file, but I am not sure. I'm not sure why you'd expect them to want another copy of the file. If they selected to open that file again, then that's what they should get, no?
(In reply to comment #15) > (In reply to comment #14) > > Hey, thanks for the comments. I am implementing this, but then got stuck with > > the correct functionality for the following use case. Suppose you already have > > a document open, say "file1.pdf", and you open a new window from the App Menu, > > and then click again in "file1.pdf", which should be the correct behavior? With > > this, it makes sense to me that the intention of the user is to open a > > different copy of the file, but I am not sure. > > I'm not sure why you'd expect them to want another copy of the file. If they > selected to open that file again, then that's what they should get, no? Sure. But if the old windows is around. Shoul we change the new window to that file or just present the old windows... if we just present the old window what do we do with new window? I meant if i open a new window and then open a file it was already opened in another window,what sould be the behavior with this new window.
Yes, bring it to front.
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > Hey, thanks for the comments. I am implementing this, but then got stuck with > > > the correct functionality for the following use case. Suppose you already have > > > a document open, say "file1.pdf", and you open a new window from the App Menu, > > > and then click again in "file1.pdf", which should be the correct behavior? With > > > this, it makes sense to me that the intention of the user is to open a > > > different copy of the file, but I am not sure. > > > > I'm not sure why you'd expect them to want another copy of the file. If they > > selected to open that file again, then that's what they should get, no? > > Sure. But if the old windows is around. Shoul we change the new window to that > file or just present the old windows... if we just present the old window what > do we do with new window? I meant if i open a new window and then open a file > it was already opened in another window,what sould be the behavior with this > new window. Sorry for the slow response! I can imagine cases where someone wants to view the same document in two separate windows (such as looking at different pages in a book). Perhaps it would be good to follow gedit here - open the file in a new window, but show an info bar, like: Document foo is already open in another window [ View Original ] [ x ] Where "View Original" would close the window and raise the other window containing the same document.
(In reply to comment #18) > I can imagine cases where someone wants to view the same document in two > separate windows (such as looking at different pages in a book). Perhaps it > would be good to follow gedit here - open the file in a new window, but show an > info bar, like: > > Document foo is already open in another window [ View Original ] [ x ] > > Where "View Original" would close the window and raise the other window > containing the same document. This sounds like a partial solution that could lead to some UI inconsistencies that would need to be addressed as well. For example, "Open a copy" (Ctrl+N) opens a duplicated window of the document. That addresses the use case you mentioned. For some context, see Bryan's comments in Bug 302034 That said, it might worth to re-consider the spatial behaviour of Evince considering that no other application uses it. That is, always open a new window regardless if it is already opened (e.g from nautilus) Carlos?
(In reply to comment #19) > (In reply to comment #18) > > I can imagine cases where someone wants to view the same document in two > > separate windows (such as looking at different pages in a book). Perhaps it > > would be good to follow gedit here - open the file in a new window, but show an > > info bar, like: > > > > Document foo is already open in another window [ View Original ] [ x ] > > > > Where "View Original" would close the window and raise the other window > > containing the same document. > > This sounds like a partial solution that could lead to some UI > inconsistencies that would need to be addressed as well. > > For example, "Open a copy" (Ctrl+N) opens a duplicated window > of the document. That addresses the use case you mentioned. To make myself clear: The inconsistency I see in the proposal would be (for a document already opened): * Open the same document using nautilus -> Bring it to front * Open the same document using any other launcher -> Bring it to front * Open the same document using recent view -> Open a duplicated window And yet still having "Open a copy" in the menu button. Recent View does not bring a clue that can open a duplicated copy. And there would be necessary to handle the case when the document is opened from the recent view, show the infobar. Which, imho, makes the code more complex.
(In reply to comment #19) ... > For example, "Open a copy" (Ctrl+N) opens a duplicated window > of the document. That addresses the use case you mentioned. That 1) relies on the user knowing that "open a copy" exists, and 2) assumes that they expect that opening the file again will switch to the existing instance. I wouldn't rely on 1, since it is generally better to assume a lack of awareness. 2 is something of an open question, but there will always be people with different expectations - so it seems like a good idea to provide an escape hatch, whatever the default is. ie. Either: * Open the file in a new window, and offer the ability to open the original instead. * Or, switch to the original instance, and offer the ability to open a duplicate in a new window.
Hey, I think I prefer to present the original instance and add an InfoBar that says something like that, "hey, you already had this file opened, if you want to open a new window with this file, you can use 'Open a copy' to do so". The advantage of going this direction, imho, is that this infobar can have a checkbox "Don't show again". What do you guys think? This would keep most of the current behavior of Evince, while addressing Allan's comments.
(In reply to comment #22) > Hey, I think I prefer to present the original instance and add an InfoBar that > says something like that, "hey, you already had this file opened, if you want > to open a new window with this file, you can use 'Open a copy' to do so". The > advantage of going this direction, imho, is that this infobar can have a > checkbox "Don't show again". What do you guys think? > > This would keep most of the current behavior of Evince, while addressing > Allan's comments. Sounds good to me.
Created attachment 283492 [details] [review] shell: Move recent view to the App Menu - Present the recent view only for empty new window. - Add a "New Window" action to the App Menu to create new empty windows.
Comment on attachment 283492 [details] [review] shell: Move recent view to the App Menu Pushed with some changes, and also landed some more fixes in follow up commits
There are still issues when launching documents from the recent view, it sometimes opens a new window instead of using the recent view window, but at least it doesn't crash. Since the remaining issues don't affect the UI changes, we can fix them later after the freeze.
*** Bug 787672 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/475.