[PATCH] specs: XI2: Remove XI prefix from events

Peter Hutterer peter.hutterer at who-t.net
Wed Feb 27 14:27:39 PST 2013


On Fri, Feb 22, 2013 at 11:22:13AM +0100, Daniel Martin wrote:
> The naming and references to events have been a mix of using an 'XI'
> prefix or not. This patch brings everything in line and removes the
> 'XI' prefix from events.

thanks! tbh, I'd rather have it the other way round, it's much less
confusing since any client will use the XI prefix.

Cheers,
   Peter

>  specs/XI2proto.txt | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
> index d30fcca..c834c5c 100644
> --- a/specs/XI2proto.txt
> +++ b/specs/XI2proto.txt
> @@ -426,7 +426,7 @@ following device modes are defined for this protocol:
>  
>  A device is identified as only one of the device modes above at any time, and
>  the touch mode may change at any time. If a device's touch mode changes, an
> -XIDeviceChangedEvent is generated.
> +DeviceChangedEvent is generated.
>  
>  [[multitouch-processing]]
>  Touch event delivery
> @@ -991,7 +991,7 @@ devices.
>  
>  If mask_len is 0, the event mask for the given device is cleared.
>  
> -The mask for XIHierarchyEvents may only be selected for XIAllDevices.
> +The mask for HierarchyEvents may only be selected for XIAllDevices.
>  Setting it for any other device results in a BadValue error.
>  
>  A client selecting for any of XI_TouchBegin, XI_TouchUpdate, or XI_TouchEnd
> @@ -1581,7 +1581,7 @@ you pass to the event-mode argument:
>       SyncPair
>          If both the device and the paired master device are frozen by the
>          client, event processing (for both devices) continues normally until
> -        the next XIButtonPress, XIButtonRelease, XIKeyPress, or XIKeyRelease
> +        the next ButtonPress, ButtonRelease, KeyPress, or KeyRelease
>          event is reported to the client for a grabbed device (button event for
>          a pointer, key event for a keyboard), at which time the devices again
>          appear to freeze. However, if the reported event causes the grab to be
> @@ -1905,7 +1905,7 @@ until server reset.
>  A property cannot be deleted by setting nitems to zero. To delete a
>  property, use XIDeleteProperty.
>  
> -This request generates an XIPropertyEvent.
> +This request generates a PropertyEvent.
>  
>  [[requests-deleteproperty]]
>  XIDeleteProperty
> @@ -1923,7 +1923,7 @@ Deletes the given property on the given device.
>          property
>              The property to delete.
>  
> -If the property is deleted, an XIPropertyEvent is generated on the device.
> +If the property is deleted, a PropertyEvent is generated on the device.
>  If the property does not exist, this request does nothing.
>  
>  [[requests-getproperty]]
> @@ -1991,7 +1991,7 @@ from 0), and its length in bytes is L. However, it is a Value error if
>  offset is given such that L is negative. The value of bytes_after is A,
>  giving the number of trailing unread bytes in the stored property. If
>  delete is True and the bytes_after is zero, the property is also
> -deleted from the device, and a XIPropertyNotify event is generated on
> +deleted from the device, and a PropertyNotify event is generated on
>  the device.  
>  
>  [[requests-xi23]]
> @@ -2143,7 +2143,7 @@ HierarchyEvent
>      info:
>          The current hierarchy information.
>  
> -An XIHierarchyEvent is sent whenever the device hierarchy been
> +A HierarchyEvent is sent whenever the device hierarchy been
>  changed. The flags specify all types of hierarchy modifiations that have
>  occured.
>  For all devices, info details the hierarchy information after the
> @@ -2162,7 +2162,7 @@ deviceid:
>           device.
>  
>  Note: Multiple devices may be affected in one hierarchy change,
> -deviceid in an XIHierarchyEvent is always the first affected
> +deviceid in a HierarchyEvent is always the first affected
>  device. Clients should ignore deviceid and instead use the devices list.
>  
>  [[events-devicechangedevent]]
> @@ -2244,7 +2244,7 @@ DeviceEvent
>      DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd,
>                                              TouchEmulatingPointer }
>  
> -An XIDeviceEvent is generated whenever the logical state of a device
> +A DeviceEvent is generated whenever the logical state of a device
>  changes in response to a button press, a button release, a motion, a key
>  press or a key release. The event type may be one of KeyPress,
>  KeyRelease, ButtonPress, ButtonRelease, Motion.
> @@ -2482,16 +2482,16 @@ zero if the device is a floating slave device.
>          Button state before the event.
>  
>  [[events-propertyevent]]
> -XIPropertyEvent
> -^^^^^^^^^^^^^^^
> +PropertyEvent
> +^^^^^^^^^^^^^
>      ┌───
> -        XIPropertyEvent
> +        PropertyEvent
>              EVENTHEADER
>              property:           ATOM
>              what:               { PropertyCreated, PropertyDeleted, PropertyModified }
>      └───
>  
> -XIPropertyEvents are sent whenever a device property is created, deleted or
> +PropertyEvents are sent whenever a device property is created, deleted or
>  modified by a client.
>  
>      property
> -- 
> 1.8.1.4
> 


More information about the xorg-devel mailing list