Re: TAKE_ACTIVITY patch

[Lubos Lunak <l lunak suse cz>]

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.

>
> So, it'd be nice to modify TAKE_ACTIVITY so that:
>
>   1) It is policy free (the window managers have total control over
>      whether and when to raise/lower/focus, etc.)
>
>   2) It allows actions upon ButtonPress as well.
>
>   3) It can handle all these cases.
>
>   4) It is extendible to further cases (button reordering for tabbed
>      browsers or the tasklist maybe?) that we haven't thought of yet.
>
> Here's my shot in the dark proposal to try to handle all those things.
> It is heavily adopted from Lubos' proposal and Olivier and Lubos'
> extended discussion.  I renamed it too, for kicks.  It isn't as cool

 The name is fine. I didn't like the name much anyway.

> as TAKE_ACTIVITY in that it's not quite as simple to implement, but I
> think it's still pretty reasonable (despite the lengthy explanation);
> it appears to be much less work than, say, _NET_WM_USER_TIME.
>
> I believe I am close to a working basic implementation (handling a few
> different widgets and cases); I do have at least part of it working
> for sliders and text selection but I'm tracking down some segfaults
> and infinite loops (bugs suck).  I thought I'd throw the idea out to
> see if I'm anywhere close to the right track so that I don't spend all
> my time going down the wrong path--especially since the gtk+ API slush
> freeze is /very/ soon and it'd be wonderful if I could get at least
> one of these proposals incorporated (or at least know enough to be
> able to state which function APIs I want so I can at least provide
> blank functions).  I'm not counting on it, but it'd be nice.
>
> _NET_WM_MOUSE_ACTION
>
> Basic idea:
>   1) Window manager receives ButtonPress, and, if window supports
>      _NET_WM_MOUSE_ACTION, it queues basic information (timestamp,
>      window) about the event but doesn't take further action.
>
>      (Unlike TAKE_ACTIVITY, here the WM doesn't send any message to
>       the client.  It seemed too much of a pain to worry about the
>       order of ButtonPress and ClientMessage events when I sometimes
>       want to take action upon ButtonPress.)

 Good idea. I'm not sure why I wanted the message from WM to the app on press. 
We just should take care the timestamp in the WM matches the timestamp in the 
app, but I think SyncPointer in XAllowEvents() uses the same for replays, so 
that should be fine.

>
>   2) Whenever the client receives a ButtonPress event, it must send a
>      _NET_WM_MOUSE_ACTION message to the root window.  The message
>      contains timestamp & window (so the WM can uniquely identify the
>      queued info), and the type of mouse action that could be
>      initiated.
>
>   3) Whenever the client receives a ButtonRelease event, it must send
>      a _NET_WM_MOUSE_ACTION message to the root window.  The message
>      contains the timestamp of the ButtonPress & window (again, so the
>      WM can uniquely identify the queued info), the timestamp of the
>      ButtonRelease, the type of mouse action, and whether there was
>      "threshold" mouse motion between ButtonPress and ButtonRelease.

 Why should the threshold be necessary? If there wasn't any such motion, then 
there wasn't any action -> say the mouse action was none.

>
> There's a few things I need to specify in more detail.  One is how I'm
> going to handle all the things being passed in the message (I have 6
> for ButtonRelease and only 5 are allowed in ClientMessages), another
> is that the "type of event" needs to be specified, and finally I have
> to specify how distinguish between ButtonPress and ButtonRelease in
> the _NET_WM_MOUSE_ACTION messages above.  More details about how to
> handle all this (but not in order--sorry):
>
> Specify EVENT_TYPE:
>   ButtonPress                                                 = 0
>   ButtonRelease, without intervening "threshold" mouse motion = 1
>   ButtonRelease, with intervening "threshold" mouse motion    = 2
>
> Specify ACTION_TYPE:
>   MOUSE_ACTION_NONE      = 0,
>   MOUSE_ACTION_MISC      = 1,
>   MOUSE_ACTION_DND       = 2,
>   MOUSE_ACTION_SELECTION = 3,
>   MOUSE_ACTION_SLIDING   = 4,
>   MOUSE_ACTION_WORKING   = 5
>
> Explanation of ACTION_TYPEs:
>   NONE:      No relevant mouse click-and-drag action (used, for example,
>              on buttons (no relevant drag action), or when no action
>              exists for a click at the given location)
>   MISC:      A mouse click-and-drag action not listed below (use of this
>              should be avoided; it is preferred to add an extra type
>              after gaining consensus on the wm-spec-list for extending
>              the _NET_WM_MOUSE_ACTION section of the EWMH.  It is
>              suggested that this type only be used while waiting for
>              consensus and an extension)

 This probably shouldn't have so strong wording. Getting every single widget 
which can handle mouse press+move+release to report correct type can be a lot 
of work. My Qt patch doing only the old way (i.e. only MISC) is a couple of 
lines, supporting all this won't be. Maybe only supporting MISC should be 
called a simple support or so? After all, I don't know about others, but I'd 
only rarely need this feature, so I wonder if developers would consider this 
to be worth the trouble.

>   DND:       Mouse action is or may be part of drag and drop
>   SELECTION: Mouse action is or may be part of selection (usually text
>              selection, but could include graphics or even be exclusively
>              graphics (think of office suites with mixtures of graphics
>              and text, for example))
>   SLIDING:   Mouse action is or may be part of moving a slider
>   WORKING:   Mouse action is or may be part of general working (drawing
>              in a photo editor, moving objects in a diagram editor,
>              etc.)
>
> Since I was short on fields by 1 (I needed 6; ClientMessages only have
> slots for 5), I combined ACTION_TYPE and EVENT_TYPE as follows:
>
> Define STATUS
>   STATUS = 3*ACTION_TYPE + EVENT_TYPE

 I'd like to see this at least split to bitfields, instead of such strange 
maths. But I think this is not necessary, one more field could be saved by 
having different message types in the X11 ClientMessage for every event type. 
IMHO that's a bit cleaner.

>
>
> Okay, just one more thing.  The proposal above handles policy free
> (clients merely say what happened, not "should raise" or "shouldn't
> raise"), it allows actions upon button presses, and it handles all the
> cases that have been presented so far.  To handle extensibility:
>
>   If a WM receives a STATUS greater than the values in the range it
>   knows how to handle, it MUST treat it as an ACTION_TYPE of
>   MOUSE_ACTION_MISC.  (EVENT_TYPE is still handled via the rule:
>   EVENT_TYPE = STATUS mod 3)
>
> This will allow us to add other ACTION_TYPEs later, and even older
> window managers can handle them with at least some sane default
> behavior.
>
>
> So, does this sound reasonable?  Would it be useful with some
> modifications (and with what modifications)?

 Besides what I already commented above, this looks fine to me.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/