The statement:

"This can lead to regression in programs that are programmed without such a
feature of the style in mind and are otherwise completely ok code wise."

has yet to be illustrated with actual cases. And in that case, mentioned regressions should be fixed (as actual bugs), in the widget style, disregarding the actual "default" value of the "window drag mode".

As for my position on the 'wish', mentioned in the original comment, I maintain it, and will wait for feedback from Oinheiro (which I just cc'ed).

I agrea with hugo on keeping the current defoults.
I many times drag a window out of the traditional areas just using some empty area of the window.
Plus its how I expect it to act...
Example of same behaviour is visible ontoolboxes that are close toguether... they create a spliter betwin them, wen you miss click the divider youo drag the tollbox out, Wich is heven more anoying than moving the window.... yet its concistent and expectable. I guess the fundamental problem is a small hit area on de spliter, somthing that we should adress in some clean non visible way...
As for apps were some non empty areas area actualy described as empty well, dont see that as a oxygen bug, and in a way it forces apps to be better defined...

Haven't kdegames already demonstrated that there are regressions?
And you can't expect people to patch applications as long as this is not documented in e.g. Qt reference docs what is needed to do.
This is no wish, this is a bug. You can't expect all people doing 3rd-party Qt apps to fix this (as it is no development error given Qt documentation, as discussed on kde-devel)

"Haven't kdegames already demonstrated that there are regressions?"

No. These are not regression. There is zero loss of functionality on the app side.

There is an extra feature (a new behavior) that does not conflict with any other feature, and that some users find annoying.

I agree with you that actual regressions (that is: loss of functionality) should be dealt with in oxygen style, and in oxygen style only. Not in the applications.

Alterations of oxygen's default (and non conflicting) behavior on the other hand, decided by an application dev, do not fall under this category. As is the case when an application dev writes is own custom QWidget when official widgets don't behave the way he wants. 

This is exactly what is happening with kdegames, and is why I am in contact with kdegame devs to help adress this alteration of default behavior. I am sure that "some" users will feel it as a regression, not to be able to drag the kpat main window from its card board anymore (well at least I do). Now, that's the application dev decision, and I have nothing to say against it (except maybe file a wish).

To be complete:

I also agree with you that there are some cases were this new feature results in some "usability" loss (again: to some users, and this is not a regression). 

Now I believe (and I think Pinhero also agrees) that the usability gain that comes with the feature in all other cases (and all other users) largely counterbalance the ones above, enough to justify the current default "drag windows from all empty area".

hugo +++ 
as with anything in life we have to balance the pros and cons...
the pros outnumber the cons IMO...

I see no real balance here. You already have seen that even inside KDE we already have work to do to fix "regressions" or "unwanted behaviour". How can one judge how the global impact is. Beside, are there any studies that show that the new window movement is "more usable"? Me never got the idea to drag the windows somewhere beside titlebar or perhaps menu/toolbar. (But yes, I know, I am not representable for normal user, just wanted to show that up)

I am not representable for normal users either, so that makes us even ;)
As for Nuno, it's actually his job (as a designer) to try figure what's more usable and what is not for normal users. An in my humble, possibly biased, opinion, he's been in fact quite good at it so far.

I in all honesty can't agree that a application that defines a non empty area as empty is a ok thing... An area in your application must be something, if you want it to be non empty you should specify it and not leave it to chance.
Plus its not like we have not diligently tried to solve each problem by even actively talking with apps with problems or wen it was the case solving issues in oxygen, the result was that a huge number of kde apps have now better defined ui's in that regard and that was a good thing.

I am not saying that KDE apps should not be improved for this setting, I am only saying that if you develop a plain Qt application, you are not made aware of this potential problem. Or do I miss a hint to this in QWidget docs?

No there is no hint in QWidget docs (or rather in QMainWindow doc) that any "unclaimed" mouse press+drag events might be used by some widget style (in our case), to move the window around. In the same way as there is no hint on how oxygen will actually render your widgets, or animate them. 

There are on the other hand hints about how you "claim" events, and that you should claim them, if you are using them. Which in turn, if done properly, should prevent any conflict, in the sense of "events being claimed by both the apps and oxygen's window drag feature, resulting in functionality loss".

Seams like somthing we should ask qt people to include in their documentation... since the same problems may ocour wen you say target OSX. The drag a window any empty area is becoming standard in all desktops.
Plus in the QML trend of doing things this might be heven more obvius, as hit areas usualy need to be explecitly defined, and leving them to any type of chace will lead to disaster... Btw don't think what I have just said is any were documented in the QML documentation...

cheers

I too strongly consider KDE's current status of having 'Drag from all empty areas' as default to be a very irritating bug and I strongly urge the KDE devs to get this changed to  'Drag windows from title bar only' as the default from the very next release onwards. I have several reasons to justify this.

I have no problems with 'Drag from all empty areas' remaining as an option for those who want it but it most definitely should not be enabled by default as this behaviour is NOT expected by 99% of regular computer users ie those coming from Windows, Mac or any of the other UNIX desktops and window managers such as GNOME and it can cause malfunctions in many apps. 

One such example is qtractor. If the user is running qtractor under KDE and they try dragging a box to select multiple clips they can't because the window gets moved instead. Suggesting that every dev alters their app just work round KDE's unusual and unexpected behaviour in this respect is unrealistic.

Pinheiro said 'The drag a window any empty area is becoming standard in all desktops' - is it? I've not seen this behaviour under any other OS, DE or WM. Which desktops are you referring to exactly? If some other desktop does this I'd highly recommend you not copy that behaviour as I fail to see the potential usability gain - you'll only get more frustrated users such as myself. Thankfully for KDE, I did my research, found out how to fix it (which isn't obvious at all under 4.8.x) and now I've come here to highlight this problem instead of telling people not to use KDE due to silly defaults.

Not only have I never had any problem with moving my pointer to the title bar to drag a window but it has always been standard within Linux/UNIX DE's and WM's to hold ALT and the left mouse button to drag a window and I think this is a much better solution than all the potential problems and user frustration caused by KDE's current default window drag mode.

(In reply to comment #13)
> default as this behaviour is NOT expected by 99% of regular computer users
> ie those coming from Windows, Mac or any of the other UNIX desktops and
> window managers such as GNOME and it can cause malfunctions in many apps. 
do you have any pointers to the usability studies showing that 99 % of the user base have problems with this behavior? If you don't have such a usability study it sounds to me like you don't like this feature and by that extrapolated on all users. That's pretty bad, we need to base decisions on facts.

Now this behavior has been enabled for a few years now and this report in particular has not seen any activity for more than a year which basically means that our users are very happy with this feature.

Hi Martin!

That '99% of users' (I should've said 'vast majority' instead of making up a percentage I suppose) I mention are the Windows, MacOS, GNOME, fluxbox, Amiga OS, Haiku/BeOS etc etc users who DO NOT expect a window to be dragged when you click/drag in an empty part of a window. What other desktop, except KDE, acts this way? None that I'm aware of - fact.

I can see no usability gain in having this feature as default. It only caused me frustration and wasting time researching how to get the normal, regular behavior of all other desktops - Linux and otherwise - back. Fact.

Did you read my qtractor problem caused by KDE's unusual defaults? This is only one example of many problems users may encounter as a result of this poorly reasoned default. Fact.

You are also seemingly unaware of the numerous others in this thread who are also unhappy with this behaviour being a default. Fact.

Through my involvement with various open source projects since '96 it has become clear to me, if its not obvious to you, that the majority of users out there do not bother to report bugs, make feature suggestions or provide any dev feedback whatsoever. If there are too many silly (and in this case easily fixed) or annoying problems most people will just look elsewhere for a desktop/app/util instead of taking the time and effort as I have to try and rectify the problem by providing factual, well reasoned feedback.

@Dan,

The behavior that you describe for qtractor sounds like a bug (either on the oxygen side or a coding issue on the qtractor side) that should be fixed disregarding what the default mode for kde's window dragging is. 

Would you mind filing a dedicated to that, as well as to other applications that you know of, for which the window dragging is a real *bug*, actually preventing the application to be used, rather than an *annoyance*  ?

Thanks,

Hugo

Again if it couses problem in an app that app needs fixing, and probably new bugs to be created, this option overall does not interfer with the way users use their apps, if the app is done correctly, that is if something is clicable and dragable in their app its should be declard so and not declared as background.

Now if all is properlie made and you try to drag a window using the window decoration (that is imo an abstract concept) it works trasparently so everything is fine , if your mouse by acident was 2 puxels down in one area that looked like the window decoration and you click and drag and it moves the window , you dont heven notice that it was not in the window decoration and thats fine 2 right?

If you end up knowing this feature and actualy use it like I do for example then its a feature I like.

So in a nutshell, 
This feture does not prevent you from using your ap like you are used 2.
If its causing problems its probably a specific app bug that needs fixing.
this feture does make life easyer providing biguer hit areas for a very comon desktop feature.  

P S. I dont use much other OS's but i do belive its defoult on OSX and windows 7

> If its causing problems its probably a specific app bug that needs fixing.

Well, that's nice.  Any advice how to `fix' programs that are totally ruined by this feature and that work fine otherwise?  What *exactly* must programs do to convince KDE that widgets or certain areas within windows are not fair game for click'n'drag hijacking?

In my case (http://gwyddion.net/, not written using Qt) KDE just seem to decide pretty much everything is inactive area so users are no longer able to select shapes within data displays, rotate 3D plots, ... because clicking and dragging moves the window instead.

> I dont use much other OS's but i do belive its defoult on OSX and windows 7

I might be the default, don't know, I don't use them either.   But if such feature is present in these environments, it at least works there properly. We do not get problem reports from MS Windows and OS X users -- unlike from KDE users.

@David
Sorry for the moment there is no written instruction on how to avoid conflicts with the drag window feature. I plan to write one on Kde-techbase soonish (hopefully next week).
Now, the application you mention is written with gtk and things are a bit more complex here (because of the nature of gtk with respect to Qt), so I need more check.
I just compiled and install the gwyddion application, but have no clue yet how to reproduce the problem, most likely because I have no clue how to use the app, and no file to open with it. Could you post instruction on how to reproduce the issue and possibly link me to a sample input file I could use to reproduce the issue ? I'd be able to check what's wrong (either on the app side or on the oxygen-gtk side) with this ...

Also: do you agree that "changing the default dragging mode" is in no way a solution to this specific issue: it would not fix anything, but hide it under the carpet, and any user that actually change the default, because he/she likes it with other applications for which it works well, would just encounter the exact same problem with this specific one ? 

If yes, I'd recommand to file a dedicated bug report concerning, this precise issue, rather than continue posting on this (unrelated) bug report - well: wish report.

Thanks in advance,

Hugo

PS: please file the bug to oxygen + Component=gtk2-engine, since this is the right component it applies to. 

Also, in the meanwhile you can, well, 
- change the grabbing behavior
- change gtk widget style
(would not affect any Qt app nor kde).

OK, submitted new bug 317292.

Concerning the default settings, although I do take the strongly conservative view, you are right that this is not really my concern.

I can live with current state.