There is no way to tile windows to the top and bottom of the screen. In System Settings > Shortcuts and Gestures > Global Keyboard Shortcuts > KDE Component = KWin, there are shortcuts available to "Quick Tile Window to the Left/Right" or Bottom/Top Left/Right. There is no option to tile windows to the top half or the bottom half, while extending across the entire width of the desktop. Similarly, when dragging windows around the desktop, ghost rectangles appear to allow tiling of windows to these six regions. There is no option to tile windows to the top half or bottom half. Reproducible: Always Steps to Reproduce: 1. Attempt to tile window to the top or bottom, as analogous to tiling windows to the left or right. Actual Results: Nothing. Expected Results: It should be possible to tile windows to the top or bottom.
Note that there is a similar but different bug that relates to automatic tiling of N windows. https://bugs.kde.org/show_bug.cgi?id=165933
"actual" tiling has been dropped and will re-occur via scripting "quick" tiling in this regard obviously conflicts with at least quick maximization on the upper border (and 16:9 screen ratios ;-) (the other bug is around invoking the taskbar to perform "quick" tiling, thus essentially unrelated. it only mentions vertical quick tiling)
Yes, sorry, I meant "quick" tiling. I agree that drag-and-dropping might be problematic, but the keyboard-shortcut method should be fine (as per Unity). A method to allow drag-and-dropping to the top might be to make the centre third the area for maximising the window, and the outer thirds for tiling the top half. Or vice versa. This would be similar to how dragging to the sides work, with sub-regions.
*** Bug 321405 has been marked as a duplicate of this bug. ***
here is a brianstorm link for this please go upvote it. http://forum.kde.org/viewtopic.php?f=83&t=111620
Given that it is in brainstorm now I'm going to close this report as WONTFIX. The reasons below: Thank you for your feature suggestion. Unfortunately, bugzilla is not the best place to discuss feature requests. We hardly have any users here, so we don't get a useful evaluation of whether the feature is needed. We recommend you use http://brainstorm.forum.kde.org to suggest this idea. Users are able to up/down-vote the feature request so we can get an idea of whether it's something our users wish to see and whether it is worth investing time in. If the feature request is supported on brainstorm it will automatically be recreated here in the bug tracker. Given that, I'm marking this feature request as WONTFIX for now. Note that this has nothing to do with whether we think this is a good or bad feature request.
I personally feel like it's more of a bug than a feature request. I think if quick tile didn't exist at all, it'd be a feature request, but given that it works properly with left and right, and corners, etc., I feel that the lack of support for up and down is a bug. However, I'm happy to be contradicted in this, especially if there are certain technical requirements that categorise it as so.
A feature request is the request for new functionality. Currently horizontal tiling is not supported - the functionality does not exist. This means that a report about it is of course a feature request as new functionality is requested.
One could argue semantically: that the functionality to tile windows exists in a general sense, and that the inconsistencies in some usages is a bug. But I won't. ;p I appreciate that the difference is in how you define the scope of the expected functionality.
*** Bug 329012 has been marked as a duplicate of this bug. ***
*** Bug 331158 has been marked as a duplicate of this bug. ***
*** Bug 343340 has been marked as a duplicate of this bug. ***
Adding brainstorm url
> If the feature request is supported on brainstorm it will automatically be recreated here in the bug tracker. How does this work? Given that there are multiple duplicate reports, and the forum link has more supporters, I would say this is a needed feature.
(In reply to Christoph Feck from comment #14) > > If the feature request is supported on brainstorm it will automatically be recreated here in the bug tracker. > > How does this work? Given that there are multiple duplicate reports, and the > forum link has more supporters, I would say this is a needed feature. I'm not convinced. The bug here has four duplicates which is comparable few, the brainstorm has not many people commenting and also a low number of votes. So to me there seems to be no strong demand for it.
My 5 cents, since it seems difficult to implement. My work efficiency depends on getting my workplace straight. Not being able to quickly tile windows with the keyboard the way I want it, is a show stopper. To be sure: "with the keyboard". I hate to switch from mouse to keyboard all the time. Hop, to another desktop environment. The experience is inconsistent if this is not resolved. It feels messy. Feels like a supercar with 3 wheels. If this is a show stopper for people, they won't stick around of course and vote for this. I tried.
> The bug here has four duplicates which is comparable few Martin, from the 1702 wishes reported for KWin, only 28 have more than four duplicates (I consider duplicates more important than number of votes, because it much easier to read a feature request and click "me too", instead of writing a feature proposal.) But the number of people using portrait displays is already a minority, so counting absolute numbers is not fair.
Ok, let's do the brainstorm here ;-) I could imagine three levels of feature here a) 2 shortcuts to toggle the active window into predefined positions (upper and lower half), pretty much unrelated to the present QT stuff. b) "en par" feature extension moving a window to the upper edge moves it to the upper half and for the lower edge to the lower half. This somehow clashes with "Quick Maximization", thus likely requires a mutually exclusive toggle. c) dynamic quick tiling (I think I saw that on Windows 8) Moving a window to the upper edge would maximize it. A subsequent attempt would move the present window to the opposite (ie. lower) half and the new one to the upper. Likewise the horizontal tiling would impact the quick maximized window and quarter tiling both types. Attempting to move a window to a slot (eg. the upper left corner) that is already taken, would move the present window to the next free slot, only resize (shrink) it if necessary and untile it if nothing of that is possible. (c) would somehow be feature complete and consistent, but also a fundamentally different approach to the status quo. Since I firmly believe that maximizing (and also half or quarter maximizing because your screen is large and of extreme aspect ratio) is a bug in the users brain, I'm out of position to argue what makes most sense here.
To add to Thomas's point (b), and alternative would be to utilise different regions of the upper edge. When dragging to the sides, we already see different functionality if the window is dragged to the top or bottom quarter. This obviously correlates with positioning the window to the corners. Similarly, users could drag windows to the left or right regions of the upper edge. The analogy fails a little here, as both maximisation and tiling to the top half of the screen both result in a window placement that is horizontally "centred", so perhaps a user option could be provided, to determine what the effect of each region would be. (Also, perhaps quarters would be the wrong ratio here.) Personally, (a) is the most important for me, while (b) is probably required for consistency with
To add to Thomas's point (b), an alternative would be to utilise different regions of the upper edge. When dragging to the sides, if the window is dragged to the top or bottom quarter, we already see different functions. This obviously correlates with positioning the window to the corners. Similarly, users could drag windows to the left or right regions of the upper edge. The analogy fails a little here, as both maximisation and tiling to the top half of the screen both result in a window placement that is horizontally "centred"; perhaps a user option could be provided, to determine what the effect of each region would be. (Also, perhaps quarters would be the wrong ratio here.)
*** Bug 343738 has been marked as a duplicate of this bug. ***
Git commit 2217c1038fcff0b349de13d2d3c19cf49c8eba50 by Martin Gräßlin, on behalf of Mika Allan Rauhala. Committed on 31/03/2015 at 09:10. Pushed by graesslin into branch 'master'. Add Quick Tile Window to the Top and Bottom shortcuts This adds "Quick Tile Window to the Top" and "Quick Title Window to the Bottom" shortcuts. These are useful for those using displays that are in portrait orientation. REVIEW: 123153 M +4 -0 kwinbindings.cpp M +16 -0 placement.cpp M +2 -0 scripting/workspace_wrapper.cpp M +2 -0 scripting/workspace_wrapper.h M +2 -0 workspace.h http://commits.kde.org/kwin/2217c1038fcff0b349de13d2d3c19cf49c8eba50
*** Bug 346131 has been marked as a duplicate of this bug. ***
*** Bug 350172 has been marked as a duplicate of this bug. ***
*** Bug 358812 has been marked as a duplicate of this bug. ***
*** Bug 365681 has been marked as a duplicate of this bug. ***
Another idea regarding the placement by touching the edge would be to make the window expand to the upper half of the screen when the upper edge is touched only when the screen is in portrait mode. And possibly use the right or left edge to maximize the window. I guess that tile to top and bottom would be not so common in landscape mode and the same for left/right in portrait.
@Simone you might be right about the common case but I often want to tile horizontally on a landscape display. One common use case for me is two terminals that have long lines but I only need to monitor the last couple.
Yes that's a good point. Still the behavior proposed for the portrait mode will not affect this use case in landscape, and I doubt someone wants to tile left/right in portrait, having the window be two long stripes (I may be wrong).
That would seem less common especially for horizontal languages but I imagine there may be some use cases for vertical languages.