|Summary:||Make use of KDecorationDefines::ExtendedBorderRegion in shipped decorations|
|Component:||decorations||Assignee:||KWin default assignee <kwin-bugs-null>|
|Latest Commit:||http://commits.kde.org/kde-workspace/ff9d595832c62c48d65fccc21ef4dc91394bd794||Version Fixed In:||4.10|
Description rockonthemoonfm 2012-10-02 12:38:56 UTC
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 https://git.reviewboard.kde.org/r/106715/
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 http://commits.kde.org/kde-workspace/ff9d595832c62c48d65fccc21ef4dc91394bd794
Comment 9 rockonthemoonfm 2012-11-15 11:16:47 UTC
thank you guys! looking forward to test 4.10 beta :) cheers
Comment 10 Hugo Pereira Da Costa 2012-11-15 11:33:31 UTC
@josephk 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
@josephk 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". Cheers, Hugo 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 PERFECT after all, if you want bigger grip area AND borders, make 'em larger! - you are perfectly right. thank you again, have a nice day