Re: TAKE_ACTIVITY patch

[Elijah Newren <newren gmail com>]

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

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

  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.

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


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

Thanks,
Elijah