GNOME Bugzilla – Bug 737239
Evince too wide to snap half view/split (It does not respond to Super+L/R arrow shortcut)
Last modified: 2018-05-22 15:55:14 UTC
Bug: Evince does not snap to half view when put against left or right hand side of screen by dragging or 'Super+left/right'. Works when snap to top when dragged to top or 'Super+up'. This behaviour does not occur with normal DPI screen and was noticed after fix for HIDPI screens on laptop. Steps to reproduce: Attach HIDPI display and attempt to snap PDF to side. Versions: 3.13.3.1 (compiled in F20) and 3.13.91 (stock F21 alpha release). Thanks.
Created attachment 289151 [details] before-minimum-toolbar-width The narrowest you can make evince 3.14 is ~690px. The way gnome-shell (or is it mutter?) snapping works is that it only enables side snaps if screenwidth/2 >= min window width. Evince is slightly too wide to allow snapping on common horizontal resolutions like 1024 and 1366 (1366/2=683, so it's very close for this one). It's very frustrating to not be able to half tile/snap.
As a workaround for those with 1366 horizontal resolution, if you open gnome-tweak tool and set Fonts > Scaling Factor to 0.91 then evince will be narrow enough to enable half snapping. Maybe a good enough fix would be to make the minimum width of the center title slightly smaller. This would at least fix it for 1366 screens.
This might be a consequence of using gtkheaderbar, which might be exacerbated when using the buttons to minimize/maximize/close windows.
Thanks this is a super catch I was noticing this bug but couldn't figure out why it is happening...
I'm not using any extra buttons (minimize etc) but the horizontal resolution of my screen is 2560 real, with a scaling factor of 2 so effectively a resolution of 1280? That little black box that comes up when re-sizing the window reads 1329 at full width and will only let me reduce the width until 723. Would dropping accuracy on the zoom label shave off a few precious pixels? I don't want to upset those who like 2 decimal place accuracy when using their viewer.
Darcy, the HiDPI window scaling factor only works in whole numbers. The Font scaling factor is the one that should probably be tweaked.
(In reply to comment #6) > Darcy, the HiDPI window scaling factor only works in whole numbers. The Font > scaling factor is the one that should probably be tweaked. I'm aware of what you are trying to do by reducing the text size. This still makes the window too large to snap across (but it's close) with your suggested size on this hardware. Going smaller works but makes the global text size too small for me.
*** Bug 739262 has been marked as a duplicate of this bug. ***
I changed the zoom factor to gint type and reduced the label by 3 'width units' in shell/zoom-action.c . This allowed evince to snap half view.
Nice Darcy! Care to attach the patch to this bug? https://wiki.gnome.org/GnomeLove/CodeContributionWorkflow#Submitting_patches
Created attachment 289541 [details] [review] Reduce the padding around the widgets. This one is required in addition to removing 3 characters from the zoom widget.
Created attachment 289542 [details] [review] Remove the 3 characters from the zoom widget and disp. only integer zoom levels Display integer types in zoom level and remove the 3 additional characters spacing for 123.xy%
(In reply to comment #10) > Nice Darcy! Care to attach the patch to this bug? > https://wiki.gnome.org/GnomeLove/CodeContributionWorkflow#Submitting_patches Sure. Try the zoom_to_int patch first and if that doesn't let you snap to half then try the other one. For some reason it only lets me snap to half when I have gone full screen then do 'super + left / right'.
Review of attachment 289542 [details] [review]: ::: shell/ev-zoom-action.c @@ +99,3 @@ zoom_str = g_strdup_printf ("%d%%", (gint)zoom_perc); else + zoom_str = g_strdup_printf ("%d%%", (gint)zoom_perc); If you change this line, the condition does not make sense anymore. So, if you are going to propose to not use decimal, then, you should get rid of the condition as well.
Review of attachment 289541 [details] [review]: Spacing of 6 is the recommendation of HIG. See "General guidelines" in https://developer.gnome.org/hig/stable/visual-layout.html.en Probably you might want to talk with the designers.
(In reply to comment #14) > Review of attachment 289542 [details] [review]: > > ::: shell/ev-zoom-action.c > @@ +99,3 @@ > zoom_str = g_strdup_printf ("%d%%", (gint)zoom_perc); > else > + zoom_str = g_strdup_printf ("%d%%", (gint)zoom_perc); > > If you change this line, the condition does not make sense anymore. > > So, if you are going to propose to not use decimal, then, you should get rid of > the condition as well. Yes I thought this might come up. Removing the floating point zoom will change the reference to EPSILON being used to see if the number is close enough to a round number. If you actually wanted this to be a solution to the snap problem then I'd have to remove this code for a future patch.
Carlor has the last word. It might worth to keep in mind why some things were introduced, in this case, arbitrary zoom levels was reported and discussed in Bug 410633.
I think that reducing space as Darcy is doing is a good enough approach in this case. Apart from that, a more general solution could be to set some icons in the header bar as optional or secundary, so they are only shown when there is enough space available for them. This can be a good balance for supporting small resolutions without limiting too much the number of controls in the header bar. As side effect, it opens also the posibility to customize the header bar with icons chosen by the user (In evince could be print, rotation, etc). Any way, as a general solution, the main part of the code must go in GTK+ itself, not in Evince.
*** Bug 739772 has been marked as a duplicate of this bug. ***
*** Bug 740150 has been marked as a duplicate of this bug. ***
I agree we should try to reduce the minimum window size, but I'm not sure about the solutions proposed. I guess we need to rethink the design once again, and try to remove some elements from the toolbar (for example the history navigation buttons, the view menu button, etc). I think Allan has some new designs.
*** Bug 740181 has been marked as a duplicate of this bug. ***
Why not come up with a design that hides less important buttons dynamically? It seems kind of weird to remove functionality permanently just for the smallest width not needed by everyone. (then again this bug affects me too and it's very annoying, so I can understand you want to do something about it) E.g. compare to what nautilus does with the folder breadcrumb bar: it dynamically shrinks as the available space decreases.
A few suggestions for Document Viewer 3.14.1 which don't remove functionality entirely or require new alternate ways to access it: * for the page view, "X| of Y" the maximum number doesn't seem very vital at the smallest width -> drop "of Y" * the minimum width for the title part seems a bit high, you could get away with roughly 75% of that are for the default font size in GNOME 3.14.1 * the zoom box thing in the title bar saves some clicks to do zooming, but it doesn't seem essential since you can still use the menu and the keyboard shortcuts to do that, so I'd consider this the next candidate for dropping This should save enough space to decrease the minimum width considerably.
(In reply to comment #23) > Why not come up with a design that hides less important buttons dynamically? It > seems kind of weird to remove functionality permanently just for the smallest > width not needed by everyone. (then again this bug affects me too and it's very > annoying, so I can understand you want to do something about it) > > E.g. compare to what nautilus does with the folder breadcrumb bar: it > dynamically shrinks as the available space decreases. I don't plan to remove any functionality, I'm talking about a redesign of the UI to make the toolbar less cluttered, but keeping all the current features.
(In reply to comment #24) > A few suggestions for Document Viewer 3.14.1 which don't remove functionality > entirely or require new alternate ways to access it: > > * for the page view, "X| of Y" the maximum number doesn't seem very vital at > the smallest width -> drop "of Y" > > * the minimum width for the title part seems a bit high, you could get away > with roughly 75% of that are for the default font size in GNOME 3.14.1 This is more difficult, I would probably just hide the title entirely. The thing is that GTK+ internally uses a minimum size of 20 chars for the title to make it centered, so we would need to implement our own title widget just for this. > * the zoom box thing in the title bar saves some clicks to do zooming, but it > doesn't seem essential since you can still use the menu and the keyboard > shortcuts to do that, so I'd consider this the next candidate for dropping > > This should save enough space to decrease the minimum width considerably.
*** Bug 740262 has been marked as a duplicate of this bug. ***
I have some draft guidelines on this issue, that I'm planning to add to the HIG in the not too distant future. They recommend that windows intended to be half-screened should have a minimum width of no more than 640px - ensuring that it works on displays that are 1280px and wider. The padding between widgets in the header bar is indeed a bit wider than it should be, although I personally feel that the number of widgets is the real issue here. Even if you do reduce the padding, you still end up with an almost useless title.
I am running Fedora 21 with 3.14.1 on a dell studio 1558 and I am having the same issue. I am unable to snap evince to half the screen. I am able to with every other application so it seems to be evince specific.
*** Bug 743313 has been marked as a duplicate of this bug. ***
Well, with the upgrade to gtk3 3.14.8 this seems to be fixed for me.
Created attachment 296357 [details] Blank PDF file with 9 pages
Created attachment 296358 [details] Blank PDF file with 10 pages
I am running Fedora 21 with Evince 3.14.1 and gtk3 3.14.8. The problem still occurs with PDF files with more than 9 pages... For PDF file with less than 10 pages, there is no problem. Attached files for testing.
This bug will hopefully be fixed in Evince 3.16. I am working on it. See https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/evince/evince-header-bar.png for an idea of what evince 3.16 would look like.
Thank you Jose for your answer. Actually, for me, there is no problem with the actual design even if the next one will be certainly better ! At this time, the problem only occurs with PDF files with more than 9 pages (really). I've done many tests (filename length, PDF format, number of pages) with different PDF files on my Fedora 21 system before adding a comment here.
*** Bug 745370 has been marked as a duplicate of this bug. ***
I also can't snap Evince to one side of the screen only 1366*768 screen due to this bug. Surely such a restrictive minimum window width is not even necessary for display purposes.
Unfortunately the design in evince 3.16. is not yet in a way that fixes this bug for me. My screen size is 2560 px with a scaling factor 2 making it 1280 px effectively.
yes, I know... unfortunately there was a issue I couldn't solve for 3.16. so we could nt merge the solution :( i should get to this hopefully in the net month.
This bug is not fixed in Evince 3.16.1. This bug has been fixed on Gedit 3.16.2 by allowing ellipsis on the document file name when it is snapped to the left or the right. Maybe that's the solution.
(In reply to Víctor Cuadrado from comment #41) > This bug is not fixed in Evince 3.16.1. > > This bug has been fixed on Gedit 3.16.2 by allowing ellipsis on the document > file name when it is snapped to the left or the right. Maybe that's the > solution. Victor can you please show the code/patch you mentioned on gedit 3.16.2?
I am no Gnome developer, and have no knowdledge of Gnome's codebase, but making a grep ellips on gedit 3.16.2 sources has pointed me to this part, with states the ellipsizing: https://git.gnome.org/browse/gedit/tree/gedit/gedit-window.c?h=gnome-3-16#n1096 and later this part, which sets the GTK_HEADER_BAR: https://git.gnome.org/browse/gedit/tree/gedit/gedit-window.c?h=gnome-3-16#n1181 Hope this helps.
Please fix this bug for the next version of GNOME. It shouldn't be that hard but it is actually one of those that you might call a "GNOME love bug", because its really annoying... Thanks!
Arch Linux here, with evince 3.18.2-2 mutter 3.18.3-2 gtk3 3.18.9-1 Snap half view/split is working as it should in Evince even with large (over 100, 200 pages) documents. I don't know where #732289 fits here anymore.
I can confirm as well that it works. Tested on my Arch Linux HiDPI laptop, and it snaps correctly with evince version 3.18.2.
Luis, Janosh: It depends on the resolution. On 1280w screen it does not work.
I also noticed that in GNU Denemo (gtk3 build) the same problem happens. I have a 1366w display.
Does not work with standard settings and a 2560w screen. But it works after reducing the font scaling factor from .90 to .89 with Gnome Tweaks. Just a matter of few pixels more
*** Bug 787894 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/515.