Re: TAKE_ACTIVITY patch

[Elijah Newren <newren gmail com>]

Sorry, it's me again.  But I just figured out one of the other things
that you said (yes, it took me all day thinking about it to
understand).

On Mon, 11 Oct 2004 10:05:39 -0600, Elijah Newren <newren gmail com> wrote:
> On Mon, 11 Oct 2004 17:00:13 +0200, Lubos Lunak <l lunak suse cz> wrote:

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

<snip>
> The reason I believe this wouldn't work is the following:
<blah blah blah, snip>
> As far as I can tell, what you suggest prevents the possibility of
> both choices by having the toolkit specify.  (And, I'm afraid that
> will lead to inconsistent toolkits as toolkit writers will have
> differing opinions on what should be done)
<snip>

Sorry, I'm a moron.  I just realized that I was wrong.  The
ButtonPress timestamp and window id are provided for the window
manager to be able to uniquely identify the message, so assuming the
ButtonPress message is received before the ButtonRelease message what
you say makes complete sense and provides no ambiguity.  My
implementation happens to throw away any information from the
ButtonPress message it receives and thus wasn't able to differentiate
between messages (and for some reason it never occurred to me to do
otherwise even after what you said).  But it would be easy for me to
fix that and do what you suggest.  And, it makes the spec look much
simpler and cleaner.

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

Well, I obviously shouldn't have fired off a response so quickly this
morning.  It appears that my disagreements were merely based on me not
understanding.  Sorry about that.  I'll attach the updated version of
the spec taking into account these last changes.  I'll rename the file
to have a .txt ending to see if gmail is any smarter about how to
handle it.  Hopefully I got everything right this time and I won't
need to spam everyone so much.  :-}

Index: wm-spec/wm-spec.xml
===================================================================
RCS file: /cvs/icccm-extensions/wm-spec/wm-spec.xml,v
retrieving revision 1.13
diff -u -r1.13 wm-spec.xml
--- wm-spec/wm-spec.xml	11 Jul 2004 12:29:04 -0000	1.13
+++ wm-spec/wm-spec.xml	12 Oct 2004 04:48:54 -0000
@@ -1340,6 +1340,90 @@
 See also the implementation notes on <link linkend="KILLINGWINDOWS">killing hung processes</link>.
 	</para>
 	</sect2>
+	<sect2>
+		<title>_NET_WM_MOUSE_ACTION</title>
+		<para>
+This protocol allows more control over when to raise, lower, or focus
+during mouse actions.  It can be used by the Window Manager, for
+example, to prevent raising during DND operations or to do something
+more complicated like raise a window upon ButtonPress for text
+selection and then lower it again upon ButtonRelease.  When the Window
+Manager receives a ButtonPress for a window of a participating Client,
+it can queue the timestamp and window id and wait for
+_NET_WM_MOUSE_ACTION messages from the Client.  A participating Client
+MUST send a client message event to the root window for each
+ButtonPress and ButtonRelease event as follows:</para>
+		<programlisting><![CDATA[
+type = ClientMessage
+window = the root window
+message_type = WM_PROTOCOLS
+format = 32
+data.l[0] = timestamp of ButtonPress
+data.l[1] = timestamp of ButtonRelease
+data.l[2] = the respective client window id
+data.l[3] = event_type
+data.l[4] = action_type
+]]></programlisting>
+		<para>
+The ButtonPress timestamp and client window id are used by the Window
+Manager to uniquely identify the queued action.  The ButtonRelease
+timestamp is ignored for ButtonPress events (it can simply be set to
+0).  The event_type and action_type fields are defined as follows:
+		</para>
+		<programlisting><![CDATA[
+event_type
+----------------------------------------------------------------------
+  ButtonPress   = 0
+  ButtonRelease = 1
+
+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.  This is used
+             when no action exists for a click at the given location
+             or when dragging would have no meaning (such as with
+             buttons).  It is also used on ButtonRelease if there was
+             not "threshold" mouse motion between ButtonPress and
+             ButtonRelease.
+  MISC:      A mouse click-and-drag action not listed below.  This
+             can be used by a Client that only wants to provide basic
+             support for _NET_WM_MOUSE_ACTION.  It can also be used by
+             a Client for actions that don't fit into the other
+             categories while waiting for this list of action_types to
+             be officially extended.
+  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.)
+]]></programlisting>
+		<para>
+If there is sufficient ("threshold") mouse motion between ButtonPress
+and ButtonRelease events, then the ButtonRelease action_type MUST
+match the action_type of the corresponding ButtonPress event.
+Otherwise, the ButtonRelease action_type MUST be MOUSE_ACTION_NONE.
+If a Window Manager receives an action_type value greater than it
+recognizes, it MUST treat the action_type as MOUSE_ACTION_MISC.
+		</para>
+		<para>
+It's entirely up to the Window Manager how to react on receiving a
+_NET_WM_MOUSE_ACTION message.  Usually, it would ignore many of the
+messages and raise or activate just after receiving certain ones,
+depending on its configuration.
+		</para>
+	</sect2>
 	<sect2><title>_NET_WM_HANDLED_ICONS</title>
 	<programlisting><![CDATA[
 _NET_WM_HANDLED_ICONS