Re: Disabling Oxygen's window dragging for specific QWidgets?
On Monday, May 16, 2011 07:52:26 AM Christoph Cullmann wrote: > Beside I doubt that 3rd-party Qt application developers want to work around > that issue. That really should be an optional setting (maybe even with > warning the user that this can result in interesting behaviour for some > applications) Once again, can somebody check what is the behaviour on Qt Cocoa ? because Cocoa applications can be dragged from anywhere... If Qt Cocoa apps have the same behaviour then there is no reason at all to disable it in Oxygen. If Qt Cocoa has the same behaviour though the Game's issue doesn't happend, then is something to look into and try to fix it in Qt/Styles. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Monday, May 16, 2011 09:55:22 am Alex Fiestas wrote: > On Monday, May 16, 2011 07:52:26 AM Christoph Cullmann wrote: > > Beside I doubt that 3rd-party Qt application developers want to work > > around that issue. That really should be an optional setting (maybe even > > with warning the user that this can result in interesting behaviour for > > some applications) > > Once again, can somebody check what is the behaviour on Qt Cocoa ? because > Cocoa applications can be dragged from anywhere... If Qt Cocoa apps have > the same behaviour then there is no reason at all to disable it in Oxygen. > > If Qt Cocoa has the same behaviour though the Game's issue doesn't happend, > then is something to look into and try to fix it in Qt/Styles. That makes zero sense, for example our applications only work on Windows and Linux X11, we are really not interested if Cocoa might do such stuff neither would we test for it to be working. We expect, that if we test an application on our two target architectures that it works and not that it stop working given some new default style of the user. If the user activates such stuff (and may got warned) it is no problem, but you can't expect third party people to test any new KDE default style (and to backport the fixes to their software out in the wild since 1-2 years :/ Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
To this point I think everything has been said (multiple times) on this thread already, and am not seing anything new with respect to what was already discussed few kde releases ago. Ultimately, I believe that the decision about what the default settings for Oxygen's "window drag" feature is Nuno (who designs oxygen) and me (who develops oxygen) to make (unless, of course, someone else wants to step in and take the job: this is open source). The reasons for the current defaults have already been motivated in this thread and elsewhere. As far as I'm concerned, unless Nuno thinks otherwise, this will not change. Among these reasons: the feature is actually working - in a consistent way -, for the vast majority of applications. (I think Todd's summary of the situation is quite comprehensive and correct with that respect, even though some people decided to simply ignore the corresponding emails) Whether people like it or not is a separate (and irrelevant) issue. This thread has already shown that for each person hating the feature you can find one loving it. To some extent, choices made by other toolkits (cocoa, gtk, whatever), other widgets styles, etc. are also unrelated and irrelevant. ... As was already stated, we will help fixing, either on the style level, or on the application level, the applications for which the window drag feature conflicts with normal use of the application (which has to be decided, in my oppinion by both apps and oxygen devs on a per application level), has we have already done in the past. Feel free to forward to Oxygen all the related bug reports that app receive, we *will* address them (just like we did adress the original issue that started this otherwise overly highjacked thread). regards, Hugo On Monday, May 16, 2011 07:52:26 AM Christoph Cullmann wrote: Beside I doubt that 3rd-party Qt application developers want to work around that issue. That really should be an optional setting (maybe even with warning the user that this can result in interesting behaviour for some applications) Once again, can somebody check what is the behaviour on Qt Cocoa ? because Cocoa applications can be dragged from anywhere... If Qt Cocoa apps have the same behaviour then there is no reason at all to disable it in Oxygen. If Qt Cocoa has the same behaviour though the Game's issue doesn't happend, then is something to look into and try to fix it in Qt/Styles. That makes zero sense, for example our applications only work on Windows and Linux X11, we are really not interested if Cocoa might do such stuff neither would we test for it to be working. We expect, that if we test an application on our two target architectures that it works and not that it stop working given some new default style of the user. If the user activates such stuff (and may got warned) it is no problem, but you can't expect third party people to test any new KDE default style (and to backport the fixes to their software out in the wild since 1-2 years :/ Greetings Christoph >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
so turn it off On Sun, May 15, 2011 at 7:36 PM, johnmS2 wrote: > On 05/15/2011 10:54 AM, todd rme wrote: > > game board unless the game specifically calls for dragging). I would > > hardly call that a "mess". > > > > So far, the complaints are mostly hypothetical. But in practice it > > isn't a major issue. > > > > -Todd > > Hi! > > Ok then +1 real world complaints: > > I as a user strongly dislike this new dragging behavior. It is most > irritating, especially when one is using a typical notebook touchpad > with tap-to-click enabled. > > -johnm > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > unsubscribe << > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Mon, May 16, 2011 at 4:38 AM, Hugo Pereira Da Costa < h...@oxygen-icons.org> wrote: > > To this point I think everything has been said (multiple times) on this > thread already, and am not seing anything new with respect to what was > already discussed few kde releases ago. > > > Ultimately, I believe that the decision about what the default settings for > Oxygen's "window drag" feature is Nuno (who designs oxygen) and me (who > develops oxygen) to make (unless, of course, someone else wants to step in > and take the job: this is open source). > > > The reasons for the current defaults have already been motivated in this > thread and elsewhere. > As far as I'm concerned, unless Nuno thinks otherwise, this will not > change. > > > Among these reasons: the feature is actually working - in a consistent way > -, for the vast > majority of applications. > (I think Todd's summary of the situation is quite comprehensive and correct > with that respect, even though some people decided to simply ignore the > corresponding emails) > > > Whether people like it or not is a separate (and irrelevant) issue. This > thread has already shown that for each person hating the feature you can > find one loving it. > > > To some extent, choices made by other toolkits (cocoa, gtk, whatever), > other widgets styles, etc. are also unrelated and irrelevant. > > > ... > > As was already stated, we will help fixing, either on the style level, or > on the application level, the applications for which the window drag feature > conflicts with normal use of the application (which has to be decided, in my > oppinion by both apps and oxygen devs on a per application level), has we > have already done in the past. > > > Feel free to forward to Oxygen all the related bug reports that app > receive, we *will* address them (just like we did adress the original issue > that started this otherwise overly highjacked thread). > > > regards, > > Hugo > > > > > On Monday, May 16, 2011 07:52:26 AM Christoph Cullmann wrote: > > Beside I doubt that 3rd-party Qt application developers want to work > around that issue. That really should be an optional setting (maybe even > with warning the user that this can result in interesting behaviour for > some applications) > > Once again, can somebody check what is the behaviour on Qt Cocoa ? because > Cocoa applications can be dragged from anywhere... If Qt Cocoa apps have > the same behaviour then there is no reason at all to disable it in Oxygen. > > If Qt Cocoa has the same behaviour though the Game's issue doesn't happend, > then is something to look into and try to fix it in Qt/Styles. > > That makes zero sense, for example our applications only work on Windows and > Linux X11, we are really not interested if Cocoa might do such stuff neither > would we test for it to be working. > > We expect, that if we test an application on our two target architectures that > it works and not that it stop working given some new default style of the > user. If the user activates such stuff (and may got warned) it is no problem, > but you can't expect third party people to test any new KDE default style (and > to backport the fixes to their software out in the wild since 1-2 years :/ > > Greetings > Christoph > > > > Count me as someone who loves the feature :) > > Is it possible to perhaps trap for the first time that a user drags on a > non-title bar part of the window and throw up a help page that lets the user > know what is happening and offers them a choice about if they want it turned > on or not? After they make a decision at this point, their selected > behaviour would be set and they'd have to go to the control panel to turn it > on/off thereafter. > > The is feature really does need to be on by default for it to be > discoverable for average users (myself included), but perhaps how to turn it > off could be brought forward in an elegant way that: advertises the feature, > allows for point-of-contact configuration and teaches the user about where > to find this (and other related) features in kcontrol. > > This same pattern of detecting first use of a feature that may not be > familiar to all users could be reused in other areas and could provide a > nice introduction to the desktop for those unfamiliar with it (and of course > would have a checkbox for "don't show me any more 1st run helpers"). >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Monday, May 16, 2011 10:38:51 am Hugo Pereira Da Costa wrote: > To this point I think everything has been said (multiple times) on this > thread already, and am not seing anything new with respect to what was > already discussed few kde releases ago. > > > Ultimately, I believe that the decision about what the default settings > for Oxygen's "window drag" feature is Nuno (who designs oxygen) and me > (who develops oxygen) to make (unless, of course, someone else wants to > step in and take the job: this is open source). > > > The reasons for the current defaults have already been motivated in this > thread and elsewhere. > As far as I'm concerned, unless Nuno thinks otherwise, this will not > change. > > > Among these reasons: the feature is actually working - in a consistent > way -, for the vast > majority of applications. > (I think Todd's summary of the situation is quite comprehensive and > correct with that respect, even though some people decided to simply > ignore the corresponding emails) > > > Whether people like it or not is a separate (and irrelevant) issue. This > thread has already shown that for each person hating the feature you can > find one loving it. > > > To some extent, choices made by other toolkits (cocoa, gtk, whatever), > other widgets styles, etc. are also unrelated and irrelevant. > > > ... > > As was already stated, we will help fixing, either on the style level, > or on the application level, the applications for which the window drag > feature conflicts with normal use of the application (which has to be > decided, in my oppinion by both apps and oxygen devs on a per > application level), has we have already done in the past. > > Feel free to forward to Oxygen all the related bug reports that app > receive, we will address them (just like we did adress the original > issue that started this otherwise overly highjacked thread). With that opinion, I can only conclude: Commercial vendors of Qt software must enforce an own style and not use the set default, otherwise their applications might break, even with a default KDE desktop. And no, bug report forwarding doesn't help at all, if you are no open-source application. (and is even ugly for open-source apps, given your old versions don't work) Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On 16.05.11 10:38:51, Hugo Pereira Da Costa wrote: > > To this point I think everything has been said (multiple times) on > this thread already, and am not seing anything new with respect to > what was already discussed few kde releases ago. Maybe its time for KDE SC to find a better working style then to use as its default... > Ultimately, I believe that the decision about what the default > settings for Oxygen's "window drag" feature is Nuno (who designs > oxygen) and me (who develops oxygen) to make (unless, of course, > someone else wants to step in and take the job: this is open > source). Thats correct for any style out there, but IMHO not for the default style that KDE ships. That style should not break user apps in strange ways, just because it can. I don't know how this stuff works technically on MacOSX Cocoa, but I did test Qt apps there and the only thing that one can use to drag the window is the empty toolbar area (tested designer and assistant as well as portedasteroids). I'm assuming there's a way on Cocoa to let the Platform/Style know that a given widget allows user-interaction and hence shouldn't be used to drag the window. Until you add such an API to Qt styles I think its inapropriate for the default KDE style to have window-dragging enabled on everything thats not explicitly disabling it by handling mouse events itself. At least disable it by default... Anyway, thats just my last opinion on the matter, I'm glag I'm not using a style that enforces me to decide which apps to use based on how good/bad they behave with that style. Andreas >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Monday 16 May 2011 10:38:51 Hugo Pereira Da Costa wrote: Let me sum up before i go back and contemplate the change of culture in kde. > Ultimately, I believe that the decision about what the default settings > for Oxygen's "window drag" feature is Nuno (who designs oxygen) and me > (who develops oxygen) to make (unless, of course, someone else wants to > step in and take the job: this is open source). So the question is if he is even aware of the discussion. > The reasons for the current defaults have already been motivated in this > thread and elsewhere. > As far as I'm concerned, unless Nuno thinks otherwise, this will not change. The only reason i got is we want it and we can make it. There was no explanation why this feature is superios to alt + mousebutton. > Among these reasons: the feature is actually working - in a consistent > way -, for the vast > majority of applications. > (I think Todd's summary of the situation is quite comprehensive and > correct with that respect, even though some people decided to simply > ignore the corresponding emails) So you guys introduce unwanted, annoying behaviour into unsuspecting applications. As an example all dockwidget using applications (Kontact, Kmail, kdevelop, dolphin, konqueror ... ) where you drag the application instead of resizing the docks if you are just one pixel off. Resize it depending on its state and sometimes move it by a hundred or more pixel if i accidently click and move one pixel. You do that for all qt based applications from the outside. You call that a feature and answer with: (from another mail) so turn it off . Remember it is not part of any standard kde option dialog. You have to start oxygen-settings to disable it for all those application that have nothing in common with oxygen. You ignore people telling you it is a problem with > author: johnmS2 > Especially when one is using a typical notebook touchpad > with tap-to-click enabled. You ignore people like me who have to drive their mouse with their left hand because of propblems with the arm and back. I am righthanded which means i am a bit clumsy using it. You ignore that i told you i trigger that feature accidently. Your answer: > toddrme > when we have some minor consistency issues, all from one class of > application, that users are unlikely to notice unless they are > specifically looking for it (most users aren't going to drag on the > game board unless the game specifically calls for dragging). I would > hardly call that a "mess". > Hugo: > Among these reasons: the feature is actually working - in a consistent > way -, for the vast > majority of applications. > (I think Todd's summary of the situation is quite comprehensive and > correct with that respect, even though some people decided to simply > ignore the corresponding emails) I especially like the "unlikely to notice" in light of a myriad of bug reports and even you guys acknowledging that this feature has problems. And the "vast majority of applications" where application include all qt based applications which can be totally unrelated to kde. > Whether people like it or not is a separate (and irrelevant) issue. This > thread has already shown that for each person hating the feature you can > find one loving it. Agreed. > To some extent, choices made by other toolkits (cocoa, gtk, whatever), > other widgets styles, etc. are also unrelated and irrelevant. Absolutly agreed. > As was already stated, we will help fixing, either on the style level, > or on the application level, the applications for which the window drag > feature conflicts with normal use of the application (which has to be > decided, in my oppinion by both apps and oxygen devs on a per > application level), has we have already done in the past. And here is the killer. Which makes me really think kde has changed over the years. When i started people considered this an absolute nono. I was even told to not fix a REAL bug because it would break applications which would have to be adapted. So we lived with that bug. You guys introduce features that break apps and say it is ok. WE WILL FIX ALL THOSE APPS. Big words. > Feel free to forward to Oxygen all the related bug reports that app > receive, we *will* address them (just like we did adress the original > issue that started this otherwise overly highjacked thread). Remember this is about all qt applications. Will you fix my home project if i tell you to because that bug annoys me. Will you fix all ruby/python/perl whatever based applications that have problems with this feature? Will you fix all qt only kde unrelated projects that do not have a vast visibility. Will you? If the answer is no ... who will do it? Mike >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
Hi all, please try to keep emotions out of the thread - it won't help anyone. I would like to offer a compromise: move the functionality of dragging window content into the window manager. As KWin does not know about the window content, the application would have to tell KWin what content is draggable, which implies an opt-in and it would only affect the kde-workspace. But this would destroy the consistancy we currently have. Only applications opting in (that is compiled against the right version of kdelibs) would use it. Third party applications would look out of place, especially GTK application. While we could consider extending EWMH and GTK+ implementing it, I doubt it will happen as the window manager specification list is unfortunately dead. Furthermore I want to repeat that this won't fix the issues given that there are other widget styles implementing this, including the default Ubuntu GTK style (which should also affect Qt applications). If the common belief is that the style should not do something like that, now is the time to communicate this to Qt in order to fix it (or at least document it) in 5.0. Cheers Martin signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
Am Montag, 16. Mai 2011, 15:07:04 schrieben Sie: > so turn it off "People like it!" "Well, I don't." "Turn it off." "See, people like it." (?) > On Sun, May 15, 2011 at 7:36 PM, johnmS2 wrote: > > On 05/15/2011 10:54 AM, todd rme wrote: > > > game board unless the game specifically calls for dragging). I would > > > hardly call that a "mess". > > > > > > So far, the complaints are mostly hypothetical. But in practice it > > > isn't a major issue. > > > > > > -Todd > > > > Hi! > > > > Ok then +1 real world complaints: > > > > I as a user strongly dislike this new dragging behavior. It is most > > irritating, especially when one is using a typical notebook touchpad > > with tap-to-click enabled. > > > > -johnm >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Mon, May 16, 2011 at 4:23 PM, Moritz Hobe wrote: > Am Montag, 16. Mai 2011, 15:07:04 schrieben Sie: > > so turn it off > > "People like it!" > "Well, I don't." > "Turn it off." > > "See, people like it." > > (?) > > No. "_Some_ people like it. " "_Some_ others don't." Don't throw up a straw man that makes out that anyone was talking in absolutes, because both the pro- and con- sides have meticulously avoided doing so. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
Am Montag, 16. Mai 2011, 20:34:13 schrieben Sie: > On Mon, May 16, 2011 at 4:23 PM, Moritz Hobe wrote: > > Am Montag, 16. Mai 2011, 15:07:04 schrieben Sie: > > > so turn it off > > > > "People like it!" > > "Well, I don't." > > "Turn it off." > > > > "See, people like it." > > > > (?) > > No. > > "_Some_ people like it. " > "_Some_ others don't." > > Don't throw up a straw man that makes out that anyone was talking in > absolutes, because both the pro- and con- sides have meticulously avoided > doing so. Todd claimed that complaints were mostly hypothetical, so johnm noted that there were non-hypothetical cases. Telling him to turn the feature off is no solution whatsoever because that's not what the discussion is about (and I'm sure he knew - at least after the discussion that has been going on - there are ways to turn it off). It is implying that his argument is invalid, and, well, that's a way of talking in absolutes: you either like it or you should just turn it off and keep silent. (By the way: I like the feature even though it has annoyed me too when I accidentally ripped e.g. Eric5 out of the maximised mode, so: I'm not a hater) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On Mon, May 16, 2011 at 5:18 PM, Moritz Hobe wrote: > Am Montag, 16. Mai 2011, 20:34:13 schrieben Sie: > > On Mon, May 16, 2011 at 4:23 PM, Moritz Hobe wrote: > > > Am Montag, 16. Mai 2011, 15:07:04 schrieben Sie: > > > > so turn it off > > > > > > "People like it!" > > > "Well, I don't." > > > "Turn it off." > > > > > > "See, people like it." > > > > > > (?) > > > > No. > > > > "_Some_ people like it. " > > "_Some_ others don't." > > > > Don't throw up a straw man that makes out that anyone was talking in > > absolutes, because both the pro- and con- sides have meticulously avoided > > doing so. > > Todd claimed that complaints were mostly hypothetical, so johnm noted that > there were non-hypothetical cases. > Telling him to turn the feature off is no solution whatsoever because > that's > not what the discussion is about (and I'm sure he knew - at least after the > discussion that has been going on - there are ways to turn it off). > It is implying that his argument is invalid, and, well, that's a way of > talking in absolutes: you either like it or you should just turn it off and > keep silent. > > (By the way: I like the feature even though it has annoyed me too when I > accidentally ripped e.g. Eric5 out of the maximised mode, so: I'm not a > hater) > But what you wrote then and what you are now saying are different. You didn't say anything about the implementation issues or that some applications had issues with the feature you created a simplification of the arguments that resulted in a misrepresentation of one side of the argument's position. Also, the "turn it off" comment was in response to the line "I as a user strongly dislike this new dragging behavior" which is hardly a comment about an aspect of the technical implementation but is purely a comment about a preference, to which a reply of "then turn it off" seems eminently appropriate. If you'd wanted to make a point about the limitations of turning off the feature versus the technical constraints of the style feature (like you appear to be doing in your most recent post) you could have just done so from the outset. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
