Re: TAKE_ACTIVITY patch

[Olivier Chapuis <chapuis nospam lri fr>]

On Mon, Oct 11, 2004 at 05:00:13PM +0200, Lubos Lunak wrote:
> On Monday 11 of October 2004 07:01, Elijah Newren wrote:
> > On Fri, 8 Oct 2004 17:03:26 +0200, Lubos Lunak <l lunak suse cz> wrote:
> > > > Question: does the spec really need to spell out waiting for button
> > > > release, DND, etc. or can we leave this more policy-free?
> > >
> > >  I think it'd be nice to have. There's a difference between DND and
> > > selecting a text, and it'd be nice to have no raise on DND and temporary
> > > raise while the text selection is done.
> > >
> > >  On the other hand, that could be a pain to (fully) implement. All places
> > > handling press->move->release mouse would need to specify the kind, which
> > > could be many places, including application code. The Qt patch which
> > > doesn't make any difference between the actions is awfully simple. Maybe
> > > having a generic action handled in the toolkit as a fallback and the
> > > possibility for other code to specify exact action would do?
> >
> > I'm trying it out (see below).  While it is definitely more work, I
> > don't think it's so bad (it definitely feels like far less work than
> > _NET_WM_USER_TIME).
> 
>  Of course. It's rather difficult to have a single seemingly simple feature 
> that'd be more work than that :-/.
> 
> > In widgets where base class behavior isn't good 
> > enough (or where you are dealing with the base class), it appears to
> > require merely three short functions calls -- one each for the
> > ButtonPress handler, the ButtonRelease handler, and the MotionNotify
> > handler.
> >
> > >  Does perhaps somebody have at least kind of working implementation of
> > > this BTW?
> >
> > I'm getting pretty close.  Because of this and a few other things,
> > I've been thinking a fair amount about the _NET_WM_TAKE_ACTIVITY stuff
> > and been trying a few things out.  It appears there are a number of
> > issues:
> >
> > A) We (at least Rob and I) would like to have windows raise upon
> >    ButtonPress if the click is upon a widget that doesn't have any
> >    meaningful drag operation; and to raise upon ButtonRelease in other
> >    cases (it turns out that Windows XP does this, and it seems
> >    sensible).  TAKE_ACTIVITY only allows raising to happen upon
> >    ButtonRelease.
> >
> > B) Rob would like windows to raise upon ButtonPress when a slider is
> >    clicked.  I want the window raised for a slider click only on
> >    ButtonRelease and only if the slider hasn't moved.  The more I've
> >    thought about it, the more I believe Rob's argument may have merit
> >    and that he may be right for Metacity.  But I really doubt we could
> >    get everyone to agree.  Unfortunately, TAKE_ACTIVITY places the
> >    decision making into the toolkit (possibly resulting in
> >    inconsistencies among toolkits if toolkit developers disagree on
> >    the appropriate action)
> >
> > C) Olivier wants to be able to raise upon ButtonPress at the beginning
> >    of text selection and then lower upon ButtonRelease of text
> >    selection if the mouse has moved.  I don't think I'd like that.
> >    TAKE_ACTIVITY can't enable this currently, and further, it places
> >    the decision making into the toolkits instead of the window
> >    manager.
> 
>  I think you misunderstand Olivier's proposal at 
> http://mail.gnome.org/archives/wm-spec-list/2004-April/msg00025.html (that, 
> or I have misunderstood it the same way). As I read it, the app sends one 
> message back to WM right after it finds out which operation is triggered by 
> the press, and sends a second after release. That should make it both 
> policy-free and allow what you want.
>

Lubos, of course, you perfectly understand my proposal.  I will be
very happy to see this in kwin (and QT of course) as I plan to write a
small CHI paper on this and some related topics.

Regards, Olivier