Bug 307721 - Make use of KDecorationDefines::ExtendedBorderRegion in shipped decorations
Summary: Make use of KDecorationDefines::ExtendedBorderRegion in shipped decorations
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (show other bugs)
Version: git master
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
Keywords: usability
Depends on:
Reported: 2012-10-02 12:38 UTC by rockonthemoonfm
Modified: 2014-07-21 19:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.10
thomas.luebking: ReviewRequest+


Note You need to log in before you can comment on or make changes to this bug.
Description rockonthemoonfm 2012-10-02 12:38:56 UTC
KDE really should implement as soon as possible this major feature for end users (everyone is an end user after all :).
This has been already implemented in Unity and Gnome3 at least one year ago, and it's working great.
Resizing windows is a pain withouth this trick, and personally I don't want 3px thick windeco borders, or 0px/no resize area borders, like in the '90s..

Please, let me smile in 4.10 :)

Reproducible: Always
Comment 1 Thomas Lübking 2012-10-02 12:51:13 UTC
In other terms you want the oxygen resize corner to be transparent, or what?

Please don't write some generic subject and then "must be done asap." as a feature request, but focus on explaining in detail what you actually want.

If i was Martin i would by now have closed it as invalid w/o any consideration because of this fundamental flaw (so you're lucky and can fix up the request until he sees it =)
Comment 2 rockonthemoonfm 2012-10-02 14:00:04 UTC
hi Thomas,

yes you're right, he also wrote a blogpost exactly on this very topic :) !!
so I'm sorry for the emphasys.
I see no button to edit my post, hope I'm not wasted!

So the problem is very clear: draggable area for resizing windows is depending upon decoration border's width. Default in KDE is 1px and trying to resize a window in this conditions is extremely painful, bit of a bingo lottery, specially for people that can't fisically make it.
Other window managers (Compiz, Mutter) already fixed this issue adding a phantom 3px window border, and this works very well.
I don't know in a 2D environment what's gonna come out, but with the upcoming QML decorations probably things are getting easier, I don't know..
Oxygen resize corner is just a corner, I'm thinking of the borders..
Probably finding a non oxygen-only solution would be better, specially if Aurorae will overtake it in future releases.
But it's up to you, I've no coding skills, I'm sorry
Comment 3 Martin Flöser 2012-10-02 16:26:35 UTC
Invisible resize area is already supported inside KWin since I think 4.8, but there are no window decorations making use of it. Hugo, that's why you are added to CC ;-)

Unfortunately at the time of this writing it's only supported for KDecoration, not for KCommonDecroation.

I might add support for it in Aurorae as in general I like the idea, which should help as a pattern for Oxygen.
Comment 4 Thomas Lübking 2012-10-02 19:04:34 UTC
Interesting but buggy (input window is not created for present windows and sometimes not at all - pot. init bug, also resizing does not work despite the cursor changes)

-> gonna fix, assuming it's ok to move the slot to KDecoration (should it become an invocable only, since it returns the relevant data, thus makes hardly sense as a slot?)
Comment 5 rockonthemoonfm 2012-10-28 12:24:57 UTC
I'm really happy that Hugo is working to implement this wish, thanks!
4.10 feature plan is looking gorgeous :)
Comment 6 Thomas Lübking 2012-10-28 12:38:45 UTC
requires (fixing part of) this first
Comment 7 Hugo Pereira Da Costa 2012-11-09 17:16:30 UTC
ok. Fixed for oxygen with e66f43d99babff5d4a6af1e94b8361915350561e
(I forgot to add the BUG:) tag in the commit so won't appear here.
Will close this report as soon as https://git.reviewboard.kde.org/r/106715/ is pushed.
Comment 8 Thomas Lübking 2012-11-14 20:33:47 UTC
Git commit ff9d595832c62c48d65fccc21ef4dc91394bd794 by Thomas Lübking.
Committed on 03/10/2012 at 19:00.
Pushed by luebking into branch 'master'.

unlink ExtendedBorderRegion from unstable API

also fix initial mapping state
Related: bug 308994
FOXED-IN: 4.10
REVIEW: 106715

M  +3    -1    kwin/client.cpp
M  +8    -7    kwin/events.cpp
M  +1    -1    kwin/libkdecorations/kdecoration.cpp
M  +9    -11   kwin/libkdecorations/kdecoration.h

Comment 9 rockonthemoonfm 2012-11-15 11:16:47 UTC
thank you guys!
looking forward to test 4.10 beta :)
Comment 10 Hugo Pereira Da Costa 2012-11-15 11:33:31 UTC
yes, would be good. And since you're at it, would be nice if you could double-check that drag and drop is still working for you (notably in amarok). I am having some issues with it here but cannot be reproduced by others so far.
Comment 11 rockonthemoonfm 2012-11-26 16:34:03 UTC
so yesterday kde has bumped to 4.9.80 into kubuntu raring daily live images..

beside everything feeling very smooth e no bugs encountered while testing (!), I must say the only thing that caught my attention were.. oxygen window borders working as in 4.9, so without the extended border region in any application..

what to do before filing a bug to kubuntu devs?
Comment 12 Hugo Pereira Da Costa 2012-11-26 16:57:08 UTC
Extended window border is only enabled (in oxygen) for the sides that do not have a visible border.
The default borderwidth, I think, is Tiny.
If you switch (in oxygen decoration config) to either "no side borders" (my favorite), or "no borders", you will get the extended borders either "on the sides" or "on the sides and bottom".



PS: the rationale behind this choice is that extended window borders can actually be more of an annoyance than anything for users used to "visible borders", and  because, due to string freeze, I could not add an option to turn it on/off for the user.
Comment 13 rockonthemoonfm 2012-11-27 12:18:18 UTC
oh.. ok.. so after testing it again I encountered no bugs at all, neither with amarok: good!

rationales in kde are always "whimsical" :)
I asked this because 1px is too little area and i don't want 3px borders, BUT
after all, if you want bigger grip area AND borders, make 'em larger! - you are perfectly right.

thank you again, have a nice day