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 =)

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

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.

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?)

I'm really happy that Hugo is working to implement this wish, thanks!
4.10 feature plan is looking gorgeous :)

requires (fixing part of) this first
https://git.reviewboard.kde.org/r/106715/

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.

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

thank you guys!
looking forward to test 4.10 beta :)
cheers

@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.

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?

@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.

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