xglcomp

annotate doc/fixesproto.txt @ 6:3f908f812ec7

find changesets by author, revision, files, or words in the commit message
added docs
author John Tsiombikas <nuclear@member.fsf.org>
date Fri, 29 Jan 2016 10:23:08 +0200
parents
children
rev   line source
nuclear@6 1 The XFIXES Extension
nuclear@6 2 Version 4.0
nuclear@6 3 Document Revision 2
nuclear@6 4 2006-12-14
nuclear@6 5 Keith Packard
nuclear@6 6 keithp@keithp.com
nuclear@6 7
nuclear@6 8 1. Introduction
nuclear@6 9
nuclear@6 10 X applications have often needed to work around various shortcomings in the
nuclear@6 11 core X window system. This extension is designed to provide the minimal
nuclear@6 12 server-side support necessary to eliminate problems caused by these
nuclear@6 13 workarounds.
nuclear@6 14
nuclear@6 15 2. Acknowledgements
nuclear@6 16
nuclear@6 17 This extension is a direct result of requests made by application
nuclear@6 18 developers, in particular,
nuclear@6 19
nuclear@6 20 + Owen Taylor for describing the issues raised with the XEMBED
nuclear@6 21 mechanisms and SaveSet processing and his initial extension
nuclear@6 22 to handle this issue.
nuclear@6 23
nuclear@6 24 + Bill Haneman for the design for cursor image tracking.
nuclear@6 25
nuclear@6 26 + Havoc Pennington
nuclear@6 27
nuclear@6 28 + Fredrik Höglund for cursor names
nuclear@6 29
nuclear@6 30 + Deron Johnson for cursor visibility
nuclear@6 31
nuclear@6 32 3. Basic Premise
nuclear@6 33
nuclear@6 34 Requests in this extension may seem to wander all over the map of X server
nuclear@6 35 capabilities, but they are tied by a simple rule -- resolving issues raised
nuclear@6 36 by application interaction with core protocol mechanisms that cannot be
nuclear@6 37 adequately worked around on the client side of the wire.
nuclear@6 38
nuclear@6 39 4. Extension initialization
nuclear@6 40
nuclear@6 41 The client must negotiate the version of the extension before executing
nuclear@6 42 extension requests. Behavior of the server is undefined otherwise.
nuclear@6 43
nuclear@6 44 QueryVersion
nuclear@6 45
nuclear@6 46 client-major-version: CARD32
nuclear@6 47 client-minor-version: CARD32
nuclear@6 48
nuclear@6 49 ->
nuclear@6 50
nuclear@6 51 major-version: CARD32
nuclear@6 52 minor-version: CARD32
nuclear@6 53
nuclear@6 54 The client sends the highest supported version to the server and
nuclear@6 55 the server sends the highest version it supports, but no higher than
nuclear@6 56 the requested version. Major versions changes can introduce
nuclear@6 57 new requests, minor version changes introduce only adjustments to
nuclear@6 58 existing requests or backward compatible changes. It is
nuclear@6 59 the clients responsibility to ensure that the server supports
nuclear@6 60 a version which is compatible with its expectations.
nuclear@6 61
nuclear@6 62 ************* XFIXES VERSION 1 OR BETTER ***********
nuclear@6 63
nuclear@6 64 5. Save Set processing changes
nuclear@6 65
nuclear@6 66 Embedding one application within another provides a way of unifying
nuclear@6 67 disparate documents and views within a single framework. From the X
nuclear@6 68 protocol perspective, this appears similar to nested window managers; the
nuclear@6 69 embedding application "manages" the embedded windows much as a window
nuclear@6 70 manager does for top-level windows. To protect the embedded application
nuclear@6 71 from embedding application failure, it is reasonable to use the core SaveSet
nuclear@6 72 mechanism so that embedding application failure causes embedded windows to
nuclear@6 73 be preserved instead of destroyed.
nuclear@6 74
nuclear@6 75 The core save set mechanism defines the target for each save set member
nuclear@6 76 window as the nearest enclosing window not owned by the terminating client.
nuclear@6 77 For embedding applications, this nearest window is usually the window
nuclear@6 78 manager frame. The problem here is that the window manager will not
nuclear@6 79 generally expect to receive and correctly manage new windows appearing within
nuclear@6 80 that window by the save set mechanism, and will instead destroy the frame
nuclear@6 81 window in response to the client window destruction. This causes the
nuclear@6 82 embedded window to be destroyed.
nuclear@6 83
nuclear@6 84 An easy fix for this problem is to change the target of the save set member
nuclear@6 85 to a window which won't be affected by the underlying window destruction.
nuclear@6 86 XFIXES chooses the root window as the target.
nuclear@6 87
nuclear@6 88 Having embedded windows suddenly appear at the top level can confuse users,
nuclear@6 89 so XFIXES also lets the client select whether the window should end up
nuclear@6 90 unmapped after the save set processing instead of unconditionally making
nuclear@6 91 them be mapped.
nuclear@6 92
nuclear@6 93 5.1 Requests
nuclear@6 94
nuclear@6 95 ChangeSaveSet
nuclear@6 96
nuclear@6 97 window: Window
nuclear@6 98 mode: { Insert, Delete }
nuclear@6 99 target: { Nearest, Root }
nuclear@6 100 map: { Map, Unmap }
nuclear@6 101
nuclear@6 102 ChangeSaveSet is an extension of the core protocol ChangeSaveSet
nuclear@6 103 request. As in that request, mode specifies whether the indicated
nuclear@6 104 window is inserted or deleted from the save-set. Target specifies
nuclear@6 105 whether the window is reparented to the nearest non-client window as
nuclear@6 106 in the core protocol, or reparented to the root window. Map
nuclear@6 107 specifies whether the window is mapped as in the core protocol or
nuclear@6 108 unmapped.
nuclear@6 109
nuclear@6 110 6. Selection Tracking
nuclear@6 111
nuclear@6 112 Applications wishing to monitor the contents of current selections must
nuclear@6 113 poll for selection changes. XFIXES improves this by providing an event
nuclear@6 114 delivered whenever the selection ownership changes.
nuclear@6 115
nuclear@6 116 6.1 Types
nuclear@6 117
nuclear@6 118 SELECTIONEVENT { SetSelectionOwner,
nuclear@6 119 SelectionWindowDestroy,
nuclear@6 120 SelectionClientClose }
nuclear@6 121
nuclear@6 122 6.1 Events
nuclear@6 123
nuclear@6 124 SelectionNotify
nuclear@6 125
nuclear@6 126 subtype: SELECTIONEVENT
nuclear@6 127 window: Window
nuclear@6 128 owner: Window
nuclear@6 129 selection: Atom
nuclear@6 130 timestamp: Timestamp
nuclear@6 131 selection-timestamp: Timestamp
nuclear@6 132
nuclear@6 133 6.2 Requests
nuclear@6 134
nuclear@6 135 SelectSelectionInput
nuclear@6 136
nuclear@6 137 window: Window
nuclear@6 138 selection: Atom
nuclear@6 139 event-mask: SETofSELECTIONEVENT
nuclear@6 140
nuclear@6 141 Selects for events to be delivered to window when various causes of
nuclear@6 142 ownership of selection occur. Subtype indicates the cause of the
nuclear@6 143 selection ownership change. Owner is set to the current selection
nuclear@6 144 owner, or None. Timestamp indicates the time the event was
nuclear@6 145 generated while selection-timestamp indicates the timestamp used to
nuclear@6 146 own the selection.
nuclear@6 147
nuclear@6 148 7. Cursor Image Monitoring
nuclear@6 149
nuclear@6 150 Mirroring the screen contents is easily done with the core protocol or VNC
nuclear@6 151 addons, except for the current cursor image. There is no way using the core
nuclear@6 152 protocol to discover which cursor image is currently displayed. The
nuclear@6 153 cursor image often contains significant semantic content about the user
nuclear@6 154 interface. XFIXES provides a simple mechanism to discover when the cursor
nuclear@6 155 image changes and to fetch the current cursor image.
nuclear@6 156
nuclear@6 157 As the current cursor may or may not have any XID associated with it, there
nuclear@6 158 is no stable name available. Instead, XFIXES returns only the image of the
nuclear@6 159 current cursor and provides a way to identify cursor images to avoid
nuclear@6 160 refetching the image each time it changes to a previously seen cursor.
nuclear@6 161
nuclear@6 162 7.1 Types
nuclear@6 163 CURSOREVENT { DisplayCursor }
nuclear@6 164
nuclear@6 165 7.2 Events
nuclear@6 166
nuclear@6 167 CursorNotify
nuclear@6 168
nuclear@6 169 subtype: CURSOREVENT
nuclear@6 170 window: Window
nuclear@6 171 cursor-serial: CARD32
nuclear@6 172 timestamp: Timestamp
nuclear@6 173 name: Atom (Version 2 only)
nuclear@6 174
nuclear@6 175 7.3 Requests
nuclear@6 176
nuclear@6 177 SelectCursorInput
nuclear@6 178
nuclear@6 179 window: Window
nuclear@6 180 event-mask: SETofCURSOREVENT
nuclear@6 181
nuclear@6 182 This request directs cursor change events to the named window.
nuclear@6 183 Events will be delivered irrespective of the screen on which they
nuclear@6 184 occur. Subtype indicates the cause of the cursor image change
nuclear@6 185 (there is only one subtype at present). Cursor-serial is a number
nuclear@6 186 assigned to the cursor image which identifies the image. Cursors
nuclear@6 187 with different serial numbers may have different images. Timestamp
nuclear@6 188 is the time of the cursor change.
nuclear@6 189
nuclear@6 190 Servers supporting the X Input Extension Version 2.0 or higher only
nuclear@6 191 notify the clients of cursor change events for the ClientPointer, not
nuclear@6 192 of any other master pointer (see Section 4.4. in the XI2 protocol
nuclear@6 193 specificiation).
nuclear@6 194
nuclear@6 195 GetCursorImage
nuclear@6 196
nuclear@6 197 ->
nuclear@6 198
nuclear@6 199 x: INT16
nuclear@6 200 y: INT16
nuclear@6 201 width: CARD16
nuclear@6 202 height: CARD16
nuclear@6 203 x-hot: CARD16
nuclear@6 204 y-hot: CARD16
nuclear@6 205 cursor-serial: CARD32
nuclear@6 206 cursor-image: LISTofCARD32
nuclear@6 207
nuclear@6 208 GetCursorImage returns the image of the current cursor. X and y are
nuclear@6 209 the current cursor position. Width and height are the size of the
nuclear@6 210 cursor image. X-hot and y-hot mark the hotspot within the cursor
nuclear@6 211 image. Cursor-serial provides the number assigned to this cursor
nuclear@6 212 image, this same serial number will be reported in a CursorNotify
nuclear@6 213 event if this cursor image is redisplayed in the future.
nuclear@6 214
nuclear@6 215 The cursor image itself is returned as a single image at 32 bits per
nuclear@6 216 pixel with 8 bits of alpha in the most significant 8 bits of the
nuclear@6 217 pixel followed by 8 bits each of red, green and finally 8 bits of
nuclear@6 218 blue in the least significant 8 bits. The color components are
nuclear@6 219 pre-multiplied with the alpha component.
nuclear@6 220
nuclear@6 221 ************* XFIXES VERSION 2 OR BETTER ***********
nuclear@6 222
nuclear@6 223 8. Region Objects
nuclear@6 224
nuclear@6 225 The core protocol doesn't expose regions as a primitive object and this
nuclear@6 226 makes many operations more complicated than they really need to be. Adding
nuclear@6 227 region objects simplifies expose handling, the Shape extension and other
nuclear@6 228 operations. These operations are also designed to support a separate
nuclear@6 229 extension, the X Damage Extension.
nuclear@6 230
nuclear@6 231 8.1 Types
nuclear@6 232
nuclear@6 233 Region: XID
nuclear@6 234 WINDOW_REGION_KIND: { Bounding, Clip }
nuclear@6 235
nuclear@6 236 8.2 Errors
nuclear@6 237
nuclear@6 238 Region The specified region is invalid
nuclear@6 239
nuclear@6 240 8.3 Requests
nuclear@6 241
nuclear@6 242 CreateRegion
nuclear@6 243
nuclear@6 244 region: REGION
nuclear@6 245 rects: LISTofRECTANGLE
nuclear@6 246
nuclear@6 247 Creates a region initialized to the specified list of rectangles.
nuclear@6 248 The rectangles may be specified in any order, their union becomes
nuclear@6 249 the region. The core protocol allows applications to specify an
nuclear@6 250 order for the rectangles, but it turns out to be just as hard to
nuclear@6 251 verify the rectangles are actually in that order as it is to simply
nuclear@6 252 ignore the ordering information and union them together. Hence,
nuclear@6 253 this request dispenses with the ordering information.
nuclear@6 254
nuclear@6 255 Errors: IDChoice
nuclear@6 256
nuclear@6 257 CreateRegionFromBitmap
nuclear@6 258
nuclear@6 259 region: REGION
nuclear@6 260 bitmap: PIXMAP
nuclear@6 261
nuclear@6 262 Creates a region initialized to the set of 'one' pixels in bitmap
nuclear@6 263 (which must be depth 1, else Match error).
nuclear@6 264
nuclear@6 265 Errors: Pixmap, IDChoice, Match
nuclear@6 266
nuclear@6 267 CreateRegionFromWindow
nuclear@6 268
nuclear@6 269 window: Window
nuclear@6 270 kind: WINDOW_REGION_KIND
nuclear@6 271 region: Region
nuclear@6 272
nuclear@6 273 Creates a region initialized to the specified window region. See the
nuclear@6 274 Shape extension for the definition of Bounding and Clip regions.
nuclear@6 275
nuclear@6 276 Errors: Window, IDChoice, Value
nuclear@6 277
nuclear@6 278 CreateRegionFromGC
nuclear@6 279
nuclear@6 280 gc: GContext
nuclear@6 281 region: Region
nuclear@6 282
nuclear@6 283 Creates a region initialized from the clip list of the specified
nuclear@6 284 GContext.
nuclear@6 285
nuclear@6 286 Errors: GContext, IDChoice
nuclear@6 287
nuclear@6 288 CreateRegionFromPicture
nuclear@6 289
nuclear@6 290 picture: Picture
nuclear@6 291 region: Region
nuclear@6 292
nuclear@6 293
nuclear@6 294 Creates a region initialized from the clip list of the specified
nuclear@6 295 Picture.
nuclear@6 296
nuclear@6 297 Errors: Picture, IDChoice
nuclear@6 298
nuclear@6 299 DestroyRegion
nuclear@6 300
nuclear@6 301 region: Region
nuclear@6 302
nuclear@6 303 Destroys the specified region.
nuclear@6 304
nuclear@6 305 Errors: Region
nuclear@6 306
nuclear@6 307 SetRegion
nuclear@6 308
nuclear@6 309 region: Region
nuclear@6 310 rects: LISTofRECTANGLE
nuclear@6 311
nuclear@6 312 This replaces the current contents of region with the region formed
nuclear@6 313 by the union of rects.
nuclear@6 314
nuclear@6 315 CopyRegion
nuclear@6 316 source: Region
nuclear@6 317 destination: Region
nuclear@6 318
nuclear@6 319 This replaces the contents of destination with the contents of
nuclear@6 320 source.
nuclear@6 321
nuclear@6 322 UnionRegion
nuclear@6 323 IntersectRegion
nuclear@6 324 SubtractRegion
nuclear@6 325
nuclear@6 326 source1: Region
nuclear@6 327 source2: Region
nuclear@6 328 destination: Region
nuclear@6 329
nuclear@6 330 Combines source1 and source2, placing the result in destination.
nuclear@6 331 Destination may be the same as either source1 or source2.
nuclear@6 332
nuclear@6 333 Errors: Region, Value
nuclear@6 334
nuclear@6 335 InvertRegion
nuclear@6 336
nuclear@6 337 source: Region
nuclear@6 338 bounds: RECTANGLE
nuclear@6 339 destination: Region
nuclear@6 340
nuclear@6 341 The source region is subtracted from the region specified by
nuclear@6 342 bounds. The result is placed in destination, replacing its contents.
nuclear@6 343
nuclear@6 344 Errors: Region
nuclear@6 345
nuclear@6 346 TranslateRegion
nuclear@6 347
nuclear@6 348 region: Region
nuclear@6 349 dx, dy: INT16
nuclear@6 350
nuclear@6 351 The region is translated by dx, dy in place.
nuclear@6 352
nuclear@6 353 Errors: Region
nuclear@6 354
nuclear@6 355 RegionExtents
nuclear@6 356
nuclear@6 357 source: Region
nuclear@6 358 destination: Region
nuclear@6 359
nuclear@6 360 The extents of the source region are placed in the destination
nuclear@6 361
nuclear@6 362 FetchRegion
nuclear@6 363
nuclear@6 364 region: Region
nuclear@6 365 ->
nuclear@6 366 extents: RECTANGLE
nuclear@6 367 rectangles: LISTofRECTANGLE
nuclear@6 368
nuclear@6 369 The region is returned as a list of rectangles in YX-banded order.
nuclear@6 370
nuclear@6 371 Errors: Region
nuclear@6 372
nuclear@6 373 SetGCClipRegion
nuclear@6 374
nuclear@6 375 gc: GCONTEXT
nuclear@6 376 clip-x-origin, clip-y-origin: INT16
nuclear@6 377 region: Region or None
nuclear@6 378
nuclear@6 379 This request changes clip-mask in gc to the specified region and
nuclear@6 380 sets the clip origin. Output will be clipped to remain contained
nuclear@6 381 within the region. The clip origin is interpreted relative to the
nuclear@6 382 origin of whatever destination drawable is specified in a graphics
nuclear@6 383 request. The region is interpreted relative to the clip origin.
nuclear@6 384 Future changes to region have no effect on the gc clip-mask.
nuclear@6 385
nuclear@6 386 Errors: GContext, Region
nuclear@6 387
nuclear@6 388 SetWindowShapeRegion
nuclear@6 389
nuclear@6 390 dest: Window
nuclear@6 391 destKind: SHAPE_KIND
nuclear@6 392 xOff, yOff: INT16
nuclear@6 393 region: Region or None
nuclear@6 394
nuclear@6 395 This request sets the specified (by destKind) Shape extension region
nuclear@6 396 of the window to region, offset by xOff and yOff. Future changes to
nuclear@6 397 region have no effect on the window shape.
nuclear@6 398
nuclear@6 399 Errors: Window, Value, Region
nuclear@6 400
nuclear@6 401 SetPictureClipRegion
nuclear@6 402
nuclear@6 403 picture: Picture
nuclear@6 404 clip-x-origin, clip-y-origin: INT16
nuclear@6 405 region: Region or None
nuclear@6 406
nuclear@6 407 This request changes clip-mask in picture to the specified region
nuclear@6 408 and sets the clip origin. Input and output will be clipped to
nuclear@6 409 remain contained within the region. The clip origin is interpreted
nuclear@6 410 relative to the origin of the drawable associated with picture. The
nuclear@6 411 region is interpreted relative to the clip origin. Future changes
nuclear@6 412 to region have no effect on the picture clip-mask.
nuclear@6 413
nuclear@6 414 Errors: Picture, Region
nuclear@6 415
nuclear@6 416 9. Cursor Names
nuclear@6 417
nuclear@6 418 Attaching names to cursors permits some abstract semantic content to be
nuclear@6 419 associated with specific cursor images. Reflecting those names back to
nuclear@6 420 applications allows that semantic content to be related to the user through
nuclear@6 421 non-visual means.
nuclear@6 422
nuclear@6 423 9.1 Events
nuclear@6 424
nuclear@6 425 CursorNotify
nuclear@6 426
nuclear@6 427 subtype: CURSOREVENT
nuclear@6 428 window: Window
nuclear@6 429 cursor-serial: CARD32
nuclear@6 430 timestamp: Timestamp
nuclear@6 431 name: Atom or None
nuclear@6 432
nuclear@6 433 In Version 2 of the XFIXES protocol, this event adds the atom
nuclear@6 434 of any name associated with the current cursor (else None).
nuclear@6 435
nuclear@6 436 9.2 Requests
nuclear@6 437
nuclear@6 438 SetCursorName
nuclear@6 439
nuclear@6 440 cursor: CURSOR
nuclear@6 441 name: LISTofCARD8
nuclear@6 442
nuclear@6 443 This request interns name as an atom and sets that atom as the name
nuclear@6 444 of cursor.
nuclear@6 445
nuclear@6 446 Errors: Cursor
nuclear@6 447
nuclear@6 448 GetCursorName
nuclear@6 449
nuclear@6 450 cursor: CURSOR
nuclear@6 451 ->
nuclear@6 452 atom: ATOM or None
nuclear@6 453 name: LISTofCARD8
nuclear@6 454
nuclear@6 455 This request returns the name and atom of cursor. If no name is
nuclear@6 456 set, atom is None and name is empty.
nuclear@6 457
nuclear@6 458 Errors: Cursor
nuclear@6 459
nuclear@6 460 GetCursorImageAndName
nuclear@6 461
nuclear@6 462 ->
nuclear@6 463
nuclear@6 464 x: INT16
nuclear@6 465 y: INT16
nuclear@6 466 width: CARD16
nuclear@6 467 height: CARD16
nuclear@6 468 x-hot: CARD16
nuclear@6 469 y-hot: CARD16
nuclear@6 470 cursor-serial: CARD32
nuclear@6 471 cursor-atom: ATOM
nuclear@6 472 cursor-name: LISTofCARD8
nuclear@6 473 cursor-image: LISTofCARD32
nuclear@6 474
nuclear@6 475 This is similar to GetCursorImage except for including both
nuclear@6 476 the atom and name of the current cursor.
nuclear@6 477
nuclear@6 478 ChangeCursor
nuclear@6 479
nuclear@6 480 source, destination: CURSOR
nuclear@6 481
nuclear@6 482 This request replaces all references to the destination with a
nuclear@6 483 reference to source. Any existing uses of the destination cursor
nuclear@6 484 object will now show the source cursor image.
nuclear@6 485
nuclear@6 486 ChangeCursorByName
nuclear@6 487
nuclear@6 488 src: CURSOR
nuclear@6 489 name: LISTofCARD8
nuclear@6 490
nuclear@6 491 This request replaces the contents of all cursors with the specified
nuclear@6 492 name with the src cursor.
nuclear@6 493
nuclear@6 494 ************* XFIXES VERSION 3 OR BETTER ***********
nuclear@6 495
nuclear@6 496 10. Region Expansion
nuclear@6 497
nuclear@6 498 This update provides another operation on the region objects defined in
nuclear@6 499 Section 8 of this document.
nuclear@6 500
nuclear@6 501 10.1 Requests
nuclear@6 502
nuclear@6 503 ExpandRegion
nuclear@6 504 source: REGION
nuclear@6 505 destination: REGION
nuclear@6 506 left, right, top, bottom: CARD16
nuclear@6 507
nuclear@6 508 Creates destination region containing the area specified by
nuclear@6 509 expanding each rectangle in the source region by the specified
nuclear@6 510 number of pixels to the left, right, top and bottom.
nuclear@6 511
nuclear@6 512 ************* XFIXES VERSION 4 OR BETTER ***********
nuclear@6 513
nuclear@6 514 11. Cursor Visibility
nuclear@6 515
nuclear@6 516 Composite managers may want to render the cursor themselves instead of
nuclear@6 517 relying on the X server sprite drawing, this provides a way for them to
nuclear@6 518 do so without getting a double cursor image.
nuclear@6 519
nuclear@6 520 11.1 Requests
nuclear@6 521
nuclear@6 522 HideCursor
nuclear@6 523
nuclear@6 524 window: WINDOW
nuclear@6 525
nuclear@6 526 A client sends this request to indicate that it wants the
nuclear@6 527 cursor image to be hidden (i.e. to not be displayed) when
nuclear@6 528 the sprite is inside the specified window, or one of its
nuclear@6 529 subwindows. If the sprite is inside a window for which one
nuclear@6 530 or more active clients have requested cursor hiding then the
nuclear@6 531 cursor image will not be displayed.
nuclear@6 532
nuclear@6 533 Note that even though cursor hiding causes the cursor image
nuclear@6 534 to be invisible, CursorNotify events will still be sent
nuclear@6 535 normally, as if the cursor image were visible.
nuclear@6 536
nuclear@6 537 If, during a grab, one or more active clients have requested
nuclear@6 538 cursor hiding for grab window, or one of its ancestors, the
nuclear@6 539 cursor image of the grab cursor will not be displayed during
nuclear@6 540 the lifetime of that grab.
nuclear@6 541
nuclear@6 542 When a client with outstanding cursor hiding requests
nuclear@6 543 terminates its connection these requests will be deleted.
nuclear@6 544
nuclear@6 545 Servers supporting the X Input Extension Version 2.0 or higher hide
nuclear@6 546 all visible cursors in response to a HideCursor request. If a master
nuclear@6 547 pointer is created while the cursors are hidden, this master pointer's
nuclear@6 548 cursor will be hidden as well.
nuclear@6 549
nuclear@6 550 ShowCursor
nuclear@6 551
nuclear@6 552 window: WINDOW
nuclear@6 553
nuclear@6 554 A client sends this request to indicate that it wants the
nuclear@6 555 cursor image to be displayed when the sprite is inside the
nuclear@6 556 specified window, or one of its subwindows. If the sprite
nuclear@6 557 is inside a window for which no active clients have requested
nuclear@6 558 cursor hiding then the cursor image for that window will be
nuclear@6 559 displayed. In other words, if a client calls HideCursor for
nuclear@6 560 a specified window, or window subtree, this request reverses
nuclear@6 561 the effects of the HideCursor request.
nuclear@6 562
nuclear@6 563 If the client has made no outstanding HideCursor requests
nuclear@6 564 a BadMatch error is generated.
nuclear@6 565
nuclear@6 566 Servers supporting the X Input Extension Version 2.0 or higher show
nuclear@6 567 all visible cursors in response to a ShowCursor request.
nuclear@6 568
nuclear@6 569 99. Future compatibility
nuclear@6 570
nuclear@6 571 This extension is not expected to remain fixed. Future changes will
nuclear@6 572 strive to remain compatible if at all possible. The X server will always
nuclear@6 573 support version 1 of the extension protocol if requested by a client.
nuclear@6 574
nuclear@6 575 Additions to the protocol will always by marked by minor version number
nuclear@6 576 changes so that applications will be able to detect what requests are
nuclear@6 577 supported.