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