Description of problem: open a pdf with evince to position the window with 'windows key' + right,left,up,down arrows and only some work. Version-Release number of selected component (if applicable): 3.14.1 How reproducible: In regular gnome session, 'windows key' + up,down work; however right,left arrow keys do not do anything to the application - so the application cannot be snapped to the right or the left. In a wayland session, 'windows key' + arrow down works; however right,left, up arrow keys do not do anything to the application. Steps to Reproduce: 1.login under regular gnome or wayland 2. hit windows key + four directional arrows (see above for which work under wayland or regular gnome) 3. Actual results: only some of the arrow keys have an effect on the application Expected results: all the keys should work up for maximize, down for non full screen, right to snap to right 50% fo window, left to snap to left 50% of window. Additional info:
I was able to reproduce the problem. I set the keybinding for splitting window to the left to <Super>L after which it started to work. I've set the keybinding back to <Super>Left after that and the keybinding works now (also the <Super>Right works without setting it). Since it works without any change in evince now I'm reassigning this to holder of the keybinding, mutter.
(In reply to afonit from comment #0) > Expected results: > all the keys should work [...] right to snap to right 50% fo window, > left to snap to left 50% of window. This is actually only expected behavior iff the window can be resized to 50% of the monitor width - tiling is disabled when the window cannot be resized at all (like Settings) or reports a minimium width that exceeds half the width of the monitor the window is located on. With some effort, I can trigger the latter with Evince on my laptop monitor if I enable minimize and maximize buttons in window decorations and a document exceeds 100 pages. So does tiling work for you if you drag the window to the left/right monitor edge instead of using the keybinding? If not, then the window simply cannot be tiled, otherwise there's some odd issue with keybindings (odd because there's no difference between the maximize shortcut and the tiling ones, besides the actual action).
(In reply to Florian Müllner from comment #2) > So does tiling work for you if you drag the window to the left/right monitor > edge instead of using the keybinding? If not, then the window simply cannot > be tiled, otherwise there's some odd issue with keybindings (odd because > there's no difference between the maximize shortcut and the tiling ones, > besides the actual action). Dragging to the right and left does not result in the snapping. If I understand what you are saying - there is actually a calculation going on in the background that is determining if snapping the window would result in a good user experience - if so I guess I could accept that. I only reported the bug because it seemed like an inconsistent experience. (eg, most windows snap and I usually have a book(pdf) open on one side of the window and a terminal or editor opened on the right). I don't recall if Fedora20 did this, as I have been using 21 for a bit now - although when I was trying to do the above noted workflow, the behavior stuck out.
(In reply to afonit from comment #3) > Dragging to the right and left does not result in the snapping. OK, so this suggests that the window actually cannot be tiled (you can inspect the size hints by running "xprop WM_NORMAL_HINTS" and selecting the window in question). > If I understand what you are saying - there is actually a calculation going > on in the background that is determining if snapping the window would result > in a good user experience - if so I guess I could accept that. Right. There's a very strong expectation that window managers respect size hints set by an application (or in most cases: the toolkit on behalf of the application). For instance when an application tells us that its window needs to be 3-times the available screen size, that's the size we give it despite knowing that the user experience cannot be good. So resizing a window to half the monitor width is not really an option if the window requests a bigger size than that - instead we have the choice between half-assed tiling (maximize the window vertically and move it to the edge, but leave it wider than 50%) or no tiling at all. The former is bad because it breaks having two windows side-by-side without overlap (which I'd argue is the main use case for tiling), the latter is bad because it is often unexpected and confusing. It's a trade-off, and we picked the latter mostly because it was consistent with the existing maximization behavior (which gets disabled as well if a window is too big for a monitor - it's just something that effects way fewer applications than tiling, for obvious reasons). If you think that overlapping would be the better trade-off in this case, I would like to take the discussion upstream to involve the GNOME design team. (On a side note, I do think that Evince would be better off with a less crowded headerbar, but that's another upstream discussion there ...)
*** Bug 1180709 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Hi Florian, I am also affected by this. However, I am not sure your explanation is enough to solve this "puzzle". I am using an up-to-date Fedora 21 installation. I can snap windows to the left or right (by dragging the window and by using Super+left/right) as long as I don't have minimize and/or maximize buttons activated. But I guess that this is a symptom, not a direct cause. For example, within the Gnome shell session, I can snap windows just fine. I activate either minimize/maximize buttons, and I can't snap windows anymore. I tried and confirmed this with nautilus, shotwell, gedit, etc... However, this is not the case with specific applications. Firefox and Libreoffice are two examples of this: I can always snap them, with and without the minimize/maximize buttons. This is, in particular, a prominent problem in Gnome classic sessions. Maybe this is triggered by windows decorations doing something? Also, to clarify, Super+up/down is never a problem!
(In reply to santibatista from comment #7) > For example, within the Gnome shell session, I can snap windows just fine. I > activate either minimize/maximize buttons, and I can't snap windows anymore. > I tried and confirmed this with nautilus, shotwell, gedit, etc... Those use client-side window decorations, so the minimize/maximize/close buttons are part of the client window and contribute to the minimum sizes. What is happening looks more or less like this: [Some button] Title [X] <---------------------> minimum width < 1/2 monitor width => snapping works [Some button] Title [_] [0] [X] <-----------------------------> minimum width > 1/2 monitor width => snapping does not work Or simply: three buttons require more space than one button :-) > However, this is not the case with specific applications. Firefox and > Libreoffice are two examples of this: I can always snap them, with and > without the minimize/maximize buttons. Those use server-side decorations, which means that the window manager (gnome-shell) is responsible for the buttons - they are not part of the client area, so it does not matter for the minimum size of the window whether there's one titlebar button or three.
I have a laptop with two monitors. Problem on native monitor (1366x768) No problem on secondary monitor (1280x720) Also, on primary monitor, No "snap selection shading" on the right side of the screen, but there is on the left. The left side only produces a "snap selection shading" indicating "full screen".
Also, behavior changes from PDF to PDF. A PDF from LibreOffice writer does not have problems. A PDF created by GOOGLE SCAN OF A BOOK (attached) DOES cause the problem. The APP may be changing the HINT because the pages are "embedded jpg's"?
The difference between PDFs can be explained by number of pages. The PDF attached in #1229693 has 313 pages which allocates more space for the page number entry on the left side of the title bar compared to a PDF with 1 page.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.