Re: Re: Disabling Oxygen's window dragging for specific QWidgets?
On Sun, May 15, 2011 at 3:06 PM, Luciano Montanaro wrote: >> So yes, all applications have to be fixed, not the style. > > I would say 29 kdegames say otherwise. That's unrelated to the discussion at hand. Thing is, we do not exactly have any type of spare manpower over at kdegames. *hint hint* Greetings Stefan >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Re: Disabling Oxygen's window dragging for specific QWidgets?
On Wed, May 18, 2011 at 11:50 PM, Stefan Majewsky wrote: >>> So yes, all applications have to be fixed, not the style. >> >> I would say 29 kdegames say otherwise. > > That's unrelated to the discussion at hand. Thing is, we do not > exactly have any type of spare manpower over at kdegames. *hint hint* Now that I actually think about this consciously: Hugo, might it make sense to disable window grabbing completely for everything that is a QGraphicsView or a KGameCanvas? Their whole widget area contains content, in the game case even a complicated background brush. And I doubt the situation is any different for other applications using QGraphicsView. The view area should be seen by the style as content and be handled just like e.g. QListView would be handled, modulo the difference that QListView probably does The Right Thing™ by default. In other words, I suggest that the _kde_no_window_grab property be added to KGameCanvas code (trunk/KDE/kdegames/libkdegames/kgamecanvas), and that Oxygen be changed such that _kde_no_window_grab behavior is enforced on QGraphicsView-derived widgets, possibly by setting _kde_no_window_grab during polishing. Greetings Stefan >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Re: Disabling Oxygen's window dragging for specific QWidgets?
Am 18.05.2011, 23:59 Uhr, schrieb Stefan Majewsky : > Now that I actually think about this consciously: Hugo, might it make > sense to disable window grabbing completely for everything that is a > QGraphicsView or a KGameCanvas? At least QGraphicsView is added explicitly (and i assume KGameCanvas is just one?!) I thought different for Bespin, and think (NOT "know") that the reason QGraphicsView was added in the first place because some applications tend to "abuse" it for "normal" window purposes (what's usually pretty pointless) On the other hand i also think that the ability to drag a window from kpat's canvas is less critical, the annoying aspect might be to maybe not really know when this happens. Eg. kpat has no hover feedback for the cards (not even a cursor shape change) - so it relies on the pre-knowledge assumption that one can and is supposed to drag the card - and they're not just part of the fancy input. Not sure, but i guess adding a feedback there might make this less a case (and I continue to believe that misclicks are a general issue and should not occur if any avoidable) > changed such that _kde_no_window_grab behavior is enforced on > QGraphicsView-derived widgets, possibly by setting _kde_no_window_grab > during polishing. Superfluous, see above (but also a minor tech detail ;-) Cheers, Thomas >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On 05/18/2011 11:59 PM, Stefan Majewsky wrote: > On Wed, May 18, 2011 at 11:50 PM, Stefan Majewsky > wrote: So yes, all applications have to be fixed, not the style. >>> I would say 29 kdegames say otherwise. >> That's unrelated to the discussion at hand. Thing is, we do not >> exactly have any type of spare manpower over at kdegames. *hint hint* > Now that I actually think about this consciously: Hugo, might it make > sense to disable window grabbing completely for everything that is a > QGraphicsView or a KGameCanvas? Their whole widget area contains > content, in the game case even a complicated background brush. And I > doubt the situation is any different for other applications using > QGraphicsView. The view area should be seen by the style as content > and be handled just like e.g. QListView would be handled, modulo the > difference that QListView probably does The Right Thing™ by default. > Hello Stefan, > In other words, I suggest that the _kde_no_window_grab property be > added to KGameCanvas code > (trunk/KDE/kdegames/libkdegames/kgamecanvas), This, or the mouse-click stealing that I advised to the original writer of this thread is what I had in mind, to fix kdegames (meaning: to alter the normal behavior foreseen by oxygen in a way that is consistant with what kdegame devs want). I'll do that tomorrow, promise. As for QGraphicsView, I would rather have this sorted out on a case by case basis, because indeed, they sometime look just like normal windows, and therefore expected to be dragable. Cheers, Hugo > and that Oxygen be > changed such that _kde_no_window_grab behavior is enforced on > QGraphicsView-derived widgets, possibly by setting _kde_no_window_grab > during polishing. > > Greetings > Stefan >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
Am Mittwoch, 18. Mai 2011, 00:41:40 schrieb David Jarvie: > On Tuesday 17 May 2011 19:33:15 Christoph Cullmann wrote: > > Am Dienstag, 17. Mai 2011, 19:03:41 schrieb Albert Astals Cid: > > > A Tuesday, May 17, 2011, Martin Gräßlin va escriure: > > > > @all: please keep the emotions out of this thread and be > > > > constructive. I offered a possible solution for the "problem" > > > > yesterday and nobody seems to be interested in actually improving > > > > the situation, instead it seems like some serious discussion for the > > > > sake of discussion is going on. This is really discouraging and I > > > > want everyone to start being constructive again! > > > > > > I think the constructive suggestion was already given before everyone > > > started throwing knives. > > > > > > Change the default to only drag from "safe places" (i.e. toolbar and > > > status bar), let the user select if he wants to drag from the "non > > > safe places" with a warning that tells him that that setting might > > > cause conflicts with some applications. > > > > +1 > > +1 Guess our arguments or solution are not considered, if you look at the following ideas in that thread :( Greetings Christoph >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
- Ursprüngliche Mitteilung - > Am Mittwoch, 18. Mai 2011, 00:41:40 schrieb David Jarvie: > > On Tuesday 17 May 2011 19:33:15 Christoph Cullmann wrote: > > > Am Dienstag, 17. Mai 2011, 19:03:41 schrieb Albert Astals Cid: > > > > A Tuesday, May 17, 2011, Martin Gräßlin va escriure: > > > > > @all: please keep the emotions out of this thread and be > > > > > constructive. I offered a possible solution for the "problem" > > > > > yesterday and nobody seems to be interested in actually improving > > > > > the situation, instead it seems like some serious discussion for > > > > > the sake of discussion is going on. This is really discouraging > > > > > and I want everyone to start being constructive again! > > > > > > > > I think the constructive suggestion was already given before > > > > everyone started throwing knives. > > > > > > > > Change the default to only drag from "safe places" (i.e. toolbar > > > > and status bar), let the user select if he wants to drag from the > > > > "non safe places" with a warning that tells him that that setting > > > > might cause conflicts with some applications. > > > > > > +1 > > > > +1 > Guess our arguments or solution are not considered, if you look at the > following ideas in that thread :( this is not true. In fact Hugo and I discussed about it the other day on IRC. But at the moment we are in feature freeze and cannot work on any of the solutions for 4.7. Cheers Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling Oxygen's window dragging for specific QWidgets?
On 05/19/2011 06:41 AM, Christoph Cullmann wrote: > Am Mittwoch, 18. Mai 2011, 00:41:40 schrieb David Jarvie: >> On Tuesday 17 May 2011 19:33:15 Christoph Cullmann wrote: >>> Am Dienstag, 17. Mai 2011, 19:03:41 schrieb Albert Astals Cid: A Tuesday, May 17, 2011, Martin Gräßlin va escriure: > @all: please keep the emotions out of this thread and be > constructive. I offered a possible solution for the "problem" > yesterday and nobody seems to be interested in actually improving > the situation, instead it seems like some serious discussion for the > sake of discussion is going on. This is really discouraging and I > want everyone to start being constructive again! I think the constructive suggestion was already given before everyone started throwing knives. Change the default to only drag from "safe places" (i.e. toolbar and status bar), let the user select if he wants to drag from the "non safe places" with a warning that tells him that that setting might cause conflicts with some applications. >>> +1 >> +1 > Guess our arguments or solution are not considered, if you look at the > following ideas in that thread :( > Dear Christoph, others, I aknowledge the suggestion above (and the fact it has already been made in that thread), and have already expressed the fact that I disagree with it. The reason for this disagreement is that I fail to see the actual "conflicts" mentionned both in the suggestion and as a justification for it. What I have seen instead in this thread is normal behavior of both oxygen and the applications, without any actual functionality loss, and some users being annoyed by this behavior. To me this does not justify a change of the default settings. (on the other hand it does justify that the ability to change this default value is made more easily available to users, which has now been committed). I also said already that I would back off my position if Nuno disagrees with me, but unfortunately Nuno is not even aware of this discussion, because (as Martin already pointed out), it is not happening on the right mailing list, (and does not have the right title, for that matter). Hugo Side note: actual "conflicts" between oxygen and applications, for which the window-drag ability would result in functionality loss on the application side, must be fixed (and have been, for the ones i am aware of), no matter what the default value for the window drag mode is. > Greetings > Christoph > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe<< >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<