Bug 318107

Summary: Initial window placement could use the same algorithm as snapping
Product: kwin Reporter: Christoph Feck <cfeck>
Component: coreAssignee: KWin default assignee <kwin-bugs-null>
Severity: wishlist CC: ultra-shimapan
Priority: NOR Flags: thomas.luebking: ReviewRequest+
Version: git master   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
URL: https://git.reviewboard.kde.org/r/112102/
Latest Commit: Version Fixed In: 4.11.1

Description Christoph Feck 2013-04-09 22:19:59 UTC
When new windows open on an empty screen, they open at (0,0)/frame position. If they are not maximized in either direction, trying to move them will make them snap at client position, e.g. (-4,0). I understand this is useful for scrollbars etc.

The initial placement could use the same algorithm.
Comment 1 Christoph Feck 2013-08-26 17:26:07 UTC
The patch in the review request works fine. I am, however, not sure if the feature is really needed. Let me clarify:

Previously, i.e. without the patch from bug 323504, it was not possible to move a window to a place where it had originally opened, making placement inconsistent. If the patch from bug 323504 is committed, then this inconsistency is gone. In other words, I do no longer need this feature.

As long as I continue to be able to create window rules that force placement at the inner border, e.g. for my editor window, I think automatic placement to inner edges is visually distracting.

I would suggest to collect more opinions before committing. Or make it configurable (which would make it a KF5 matter).
Comment 2 Thomas Lübking 2013-08-26 17:55:11 UTC
That patch, as it is, cannot go in.
Leaving aside the "weird, osset screen config" concern (makes things more complex, but is fixable) the patch basically breaks snapping.

The purpose of snapping is to easily move the window to a predefined location - no matter which that actually is.
With the patch however, snapping to the desired position (deco/client) becomes an obstacle game - depending on how thin the border is and how much you know about the actual behavior.

Otherwise the window wil judder around clint/deco snap with mouse movements (and for a 1px borde, there's not the least preference on either around the screen edge)

Imo, the screenborders are the most valuable positions and snapping to the decoration (where the only possible action is to remove the decoration from the value position) just wasting it.
If i'm wrong and ppl. prefer visual ensurance that snapping actually worked an the window was not somehow moved too far or whatever, i'd rather suggest to revert to deco snapping, but not break snapping (esp. not as you cannot see to what you snapped since oxygen usually merges content and decoration)
Comment 3 Thomas Lübking 2013-08-27 06:07:26 UTC
Git commit 6d256b2d149c68fd08888865b8a7fafdad397296 by Thomas Lübking.
Committed on 15/08/2013 at 09:53.
Pushed by luebking into branch 'KDE/4.11'.

align zero corner placement to client, not deco
FIXED-IN: 4.11.1
REVIEW: 112102

M  +2    -1    kwin/manage.cpp
M  +26   -4    kwin/placement.cpp

Comment 4 Thomas Lübking 2013-08-27 06:34:14 UTC
Sorry, accidental commit.
It makes sense atm, but eventually needs to be reverted with the resolution of bug #323504
Comment 5 Ultra 2013-09-14 15:38:29 UTC
(In reply to comment #2)
> If i'm wrong and ppl. prefer visual ensurance that snapping actually worked
> an the window was not somehow moved too far or whatever, i'd rather suggest
> to revert to deco snapping

I would greatly appreciate it if you reverted to deco snapping!
The current snapping in 4.11.1 looks just awfully ugly, as it cuts off a good part of my window menu button, as well as the left window border, if I try to snap a window to the left border. Window borders are an important visual clue to me - if I didn't want screen borders, I would've turned them off entirely.