[2/2] PropertyNotify filters

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 fixesproto.txt |   49 +++++++++++++++++++++++++++++++++++++++++++++++++
 xfixesproto.h  |   23 +++++++++++++++++++++++
 xfixeswire.h   |    4 +++-
 3 files changed, 75 insertions(+), 1 deletions(-)

On 12/01/11 12:53, Adam Jackson wrote:
> +AddPropertyFilter
> +
> +		window:			WINDOW
> +		property:		LISTofATOM
> +		mode:			{ Replace, Prepend, Append }
> +
> +	This request modifies the property filter for the named window for
> +	the requesting client.  If mode is Prepend or Append, the listed
> +	properties are added to the list of properties for which the client
> +	will receive events.  If mode is Replace, the list of properties
> +	replaces any existing filter list.  If an empty list is sent, no
> +	events will be sent for any property changes.

Why both Prepend & Append?  Does ordering matter for semantics, or is this
just a way to let applications try to hint at ordering for performance
optimization by putting most used first?

On Thu, Dec 01, 2011 at 03:53:41PM -0500, Adam Jackson wrote:
> Signed-off-by: Adam Jackson <ajax@redhat.com>
> ---
>  fixesproto.txt |   49 +++++++++++++++++++++++++++++++++++++++++++++++++
>  xfixesproto.h  |   23 +++++++++++++++++++++++
>  xfixeswire.h   |    4 +++-
>  3 files changed, 75 insertions(+), 1 deletions(-)
> 
> diff --git a/fixesproto.txt b/fixesproto.txt
> index 1ff442f..af7da7b 100644
> --- a/fixesproto.txt
> +++ b/fixesproto.txt
> @@ -712,6 +712,55 @@ QueryAncestors
>  
>  	Errors: Window
>  
> +14. PropertyNotify filters
> +
> +The core protocol's PropertyNotify is rather noisy, as it will wake up all
> +clients listening on a given window when any property on that window
> +changes.  Typically clients are interested in only a few properties, so
> +to avoid this thundering herd a filter is introduced.
> +
> +The client must still have selected PropertyChange on the window for this
> +filter to be hit.  The new requests do not modify whether PropertyChange
> +has been selected, only the set of events that are delivered.
> +
> +14.1 Requests
> +
> +AddPropertyFilter
> +
> +		window:			WINDOW
> +		property:		LISTofATOM
> +		mode:			{ Replace, Prepend, Append }
> +
> +	This request modifies the property filter for the named window for
> +	the requesting client.  If mode is Prepend or Append, the listed
> +	properties are added to the list of properties for which the client
> +	will receive events.  If mode is Replace, the list of properties
> +	replaces any existing filter list.  If an empty list is sent, no
> +	events will be sent for any property changes.
> +
> +	If any atom in the list does not name a defined atom, BadAtom will
> +	be generated, and the property filter list is unchanged.
> +
> +	Errors: Window, Atom, Value
> +
> +RemovePropertyFilter
> +
> +		window:			WINDOW
> +		property:		LISTofATOM
> +
> +	This request modifies the property filter for the named window for
> +	the requesting client.  The listed properties are removed from the
> +	list of properties for which the client will receive events.  If
> +	an empty list is sent, the client will revert to unfiltered (core
> +	protocol) behaviour for PropertyNotify.
> +
> +	If any atom in the list does not name a defined atom, BadAtom will
> +	be generated.  If any atom in the (non-empty) list does not match
> +	an atom which the client has previously filtered for, BadMatch is
> +	generated.  In either case, the property filter list is unchanged.
> +
> +	Errors: Window, Atom, Match

I don't think we're short on request codes but RemovePropertyFilter could be
added with a mode: Remove. Though renaming the request to SetPropertyFilter
would be sensible then.

(side-node: 'Atom' should be uppercase in the texts)

Cheers,
  Peter

> +
>  99. Future compatibility
>  
>  This extension is not expected to remain fixed.  Future changes will
> diff --git a/xfixesproto.h b/xfixesproto.h
> index 717cba4..35864dc 100644
> --- a/xfixesproto.h
> +++ b/xfixesproto.h
> @@ -590,6 +590,29 @@ typedef struct {
>  
>  #define sz_xXFixesQueryAncestorsReply 32
>  
> +typedef struct {
> +    CARD8   reqType;
> +    CARD8   xfixesReqType;
> +    CARD16  length B16;
> +    CARD32  mode B32;
> +    Window  window B32;
> +    CARD32  numAtoms B32;
> +    /* list of atoms */
> +} xXFixesAddPropertyFilterReq;
> +
> +#define sz_xXFixesAddPropertyFilterReq sizeof(xXFixesAddPropertyFilterReq)
> +
> +typedef struct {
> +    CARD8   reqType;
> +    CARD8   xfixesReqType;
> +    CARD16  length B16;
> +    CARD32  Window B32;
> +    CARD32  numAtoms B32;
> +    /* list of atoms */
> +} xXFixesRemovePropertyFilterReq;
> +
> +#define sz_xXFixesRemovePropertyFilterReq sizeof(xXFixesRemovePropertyFilterReq
> +
>  #undef Barrier
>  #undef Region
>  #undef Picture
> diff --git a/xfixeswire.h b/xfixeswire.h
> index 8d2319b..b0ccdae 100644
> --- a/xfixeswire.h
> +++ b/xfixeswire.h
> @@ -92,8 +92,10 @@
>  /*************** Version 6 ******************/
>  #define X_XFixesQueryPointer		    33
>  #define X_XFixesQueryAncestors		    34
> +#define X_XFixesAddPropertyFilter	    35
> +#define X_XFixesRemovePropertyFilter	    36
>  
> -#define XFixesNumberRequests		    (X_XFixesQueryAncestors+1)
> +#define XFixesNumberRequests		    (X_XFixesRemovePropertyFilter+1)
>  
>  /* Selection events share one event number */
>  #define XFixesSelectionNotify		    0
> -- 
> 1.7.6.4
> 
> _______________________________________________
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>

On 12/2/11 12:09 AM, Peter Hutterer wrote:
> On Thu, Dec 01, 2011 at 03:53:41PM -0500, Adam Jackson wrote:
>> +RemovePropertyFilter
>> +
>> +		window:			WINDOW
>> +		property:		LISTofATOM
>> +
>> +	This request modifies the property filter for the named window for
>> +	the requesting client.  The listed properties are removed from the
>> +	list of properties for which the client will receive events.  If
>> +	an empty list is sent, the client will revert to unfiltered (core
>> +	protocol) behaviour for PropertyNotify.
>> +
>> +	If any atom in the list does not name a defined atom, BadAtom will
>> +	be generated.  If any atom in the (non-empty) list does not match
>> +	an atom which the client has previously filtered for, BadMatch is
>> +	generated.  In either case, the property filter list is unchanged.
>> +
>> +	Errors: Window, Atom, Match
>
> I don't think we're short on request codes but RemovePropertyFilter could be
> added with a mode: Remove. Though renaming the request to SetPropertyFilter
> would be sensible then.

Yeah, I went back and forth on doing this as two requests or one.  Might 
as well redo it as just one to be conservative with request numbers. 
Also REST I guess.

- ajax