xterm.c 794 KB
Newer Older
Jim Blandy's avatar
Jim Blandy committed
/* X Communication module for terminals which understand the X protocol.
Glenn Morris's avatar
Glenn Morris committed

Eli Zaretskii's avatar
Eli Zaretskii committed
Copyright (C) 1989, 1993-2022 Free Software Foundation, Inc.
Jim Blandy's avatar
Jim Blandy committed
4 5 6

This file is part of GNU Emacs.

GNU Emacs is free software: you can redistribute it and/or modify
Jim Blandy's avatar
Jim Blandy committed
it under the terms of the GNU General Public License as published by
9 10
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
Jim Blandy's avatar
Jim Blandy committed
11 12 13 14 15 16 17

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
Jim Blandy's avatar
Jim Blandy committed

/* New display code by Gerd Moellmann <gerd@gnu.org>.  */
21 22
/* Xt features made by Fred Pierresteguy.  */

23 24 25 26 27 28
/* X window system support for GNU Emacs

   This file is part of the X window system support for GNU Emacs.  It
   contains subroutines comprising the redisplay interface, setting up
   scroll bars and widgets, and handling input.

Po Lu's avatar
Po Lu committed
29 30 31
   Some of what is explained below also applies to the other window
   systems that Emacs supports, to varying degrees.  YMMV.

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80

   Emacs handles input by running pselect in a loop, which returns
   whenever there is input available on the connection to the X
   server.  On some systems, Emacs also arranges for any new input on
   that connection to send an asynchronous signal.  Whenever pselect
   returns, or such a signal is received and input is not blocked,
   XTread_socket is called and translates X11 events read by Xlib into
   struct input_events, which are then stored in the keyboard buffer,
   to be processed and acted upon at some later time.  The function
   handle_one_xevent is responsible for handling core events after
   they are filtered, and filtering X Input Extension events.  It also
   performs actions on some special events, such as updating the
   dimensions of a frame after a ConfigureNotify is sent by the X
   server to inform us that it changed.

   Before such events are translated, an Emacs build with
   internationalization enabled (the default since X11R6) will filter
   events through an X Input Method (XIM) or GTK, which might decide
   to intercept the event and send a different one in its place, for
   reasons such as enabling the user to insert international
   characters that aren't on his keyboard by typing a sequence of
   characters which are.  See the function x_filter_event and its
   callers for more details.

   Events that cause Emacs to quit are treated specially by the code
   that stores them in the keyboard buffer and generally cause an
   immediate interrupt.  Such an interrupt can lead to a longjmp from
   the code that stored the keyboard event, which isn't safe inside
   XTread_socket.  To avoid this problem, XTread_socket is provided a
   special event buffer named hold_quit.  When a quit event is
   encountered, it is stored inside this special buffer, which will
   cause the keyboard code that called XTread_socket to store it at a
   later time when it is safe to do so.

   handle_one_xevent will generally have to determine which frame an
   event should be attributed to.  This is not easy, because events
   can come from multiple X windows, and a frame can also have
   multiple windows.  handle_one_xevent usually calls the function
   x_any_window_to_frame, which searches for a frame by toplevel
   window and widget windows.  There are also some other functions for
   searching by specific types of window, such as
   x_top_window_to_frame (which only searches for frames by toplevel
   window), and x_menubar_window_to_frame (which will only search
   through frame menu bars).


   Under X, the window where keyboard input is sent is not always
Stefan Kangas's avatar
Stefan Kangas committed
   explicitly defined.  When there is a focus window, it receives what
82 83 84 85 86 87 88 89
   is referred to as "explicit focus", but when there is none, it
   receives "implicit focus" whenever the pointer enters it, and loses
   that focus when the pointer leaves.  When the toplevel window of a
   frame receives an explicit focus event (FocusIn or FocusOut), we
   treat that frame as having the current input focus, but when there
   is no focus window, we treat each frame as having the input focus
   whenever the pointer enters it, and undo that treatment when the
   pointer leaves it.  See the callers of x_detect_focus_change for
Po Lu's avatar
Po Lu committed
90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
   more details.


   The redisplay engine communicates with X through the "redisplay
   interface", which is a structure containing pointers to functions
   which output graphics to a frame.

   Some of the functions included in the redisplay interface include
   `x_clear_frame_area', which is called by the display engine when it
   determines that a part of the display has to be cleared,
   x_draw_window_cursor, which is called to perform the calculations
   necessary to display the cursor glyph with a special "highlight"
   (more on that later) and to set the input method spot location.

   Most of the actual display is performed by the function
   `x_draw_glyph_string', also included in the redisplay interface.
   It takes a list of glyphs of the same type and face, computes the
   correct graphics context for the string through the function
   `x_set_glyph_string_gc', and draws whichever glyphs it might
   contain, along with decorations such as the box face, underline and
   overline.  That list is referred to as a "glyph string".


   A graphics context ("GC") is an X server-side object which contains
   drawing attributes such as fill style, stipple, and foreground and
   background pixel values.

   Usually, one graphics context is computed for each face when it is
120 121 122 123
   about to be displayed for the first time, and this graphics context
   is the one which is used for future X drawing operations in a glyph
   string with that face.  (See `prepare_face_for_display' in
Po Lu's avatar
Po Lu committed
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144

   However, when drawing glyph strings for special display elements
   such as the cursor, or mouse sensitive text, different GCs may be
   used.  When displaying the cursor, for example, the frame's cursor
   graphics context is used for the common case where the cursor is
   drawn with the default font, and the colors of the string's face
   are the same as the default face.  In all other cases, a temporary
   graphics context is created with the foreground and background
   colors of the cursor face adjusted to ensure that the cursor can be
   distinguished from its surroundings and that the text inside the
   cursor stays visible.

   Various graphics contexts are also calculated when the frame is
   created by the function `x_make_gcs' in xfns.c, and are adjusted
   whenever the foreground or background colors change.  The "normal"
   graphics context is used for operations performed without a face,
   and always corresponds to the foreground and background colors of
   the frame's default face, the "reverse" graphics context is used to
   draw text in inverse video, and the cursor graphics context is used
   to display the cursor in the most common case.

Po Lu's avatar
Po Lu committed
145 146 147 148 149 150 151
   N.B. that some of the other window systems supported by use an
   emulation of graphics contexts to hold the foreground and
   background colors used in a glyph string, while the some others
   ports compute those colors directly based on the colors of the
   string's face and its highlight, but only on X are graphics
   contexts a data structure inherent to the window system.

Po Lu's avatar
Po Lu committed
152 153

Po Lu's avatar
Po Lu committed
154 155 156 157 158 159 160
   In (and only in) X, pixel values for colors are not guaranteed to
   correspond to their individual components.  The rules for
   converting colors into pixel values are defined by the visual class
   of each display opened by Emacs.  When a display is opened, a
   suitable visual is obtained from the X server, and a colormap is
   created based on that visual, which is then used for each frame
Po Lu's avatar
Po Lu committed
161 162 163 164 165 166

   The colormap is then used by the X server to convert pixel values
   from a frame created by Emacs into actual colors which are output
   onto the physical display.

   When the visual class is TrueColor, the colormap will be indexed
167 168 169 170 171
   based on the red, green, and blue (RGB) components of the pixel
   values, and the colormap will be statically allocated so as to
   contain linear ramps for each component.  As such, most of the
   color allocation described below is bypassed, and the pixel values
   are computed directly from the color.
Po Lu's avatar
Po Lu committed
172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210

   Otherwise, each time Emacs wants a pixel value that corresponds to
   a color, Emacs has to ask the X server to obtain the pixel value
   that corresponds to a "color cell" containing the color (or a close
   approximation) from the colormap.  Exactly how this is accomplished
   further depends on the visual class, since some visuals have
   immutable colormaps which contain color cells with pre-defined
   values, while others have colormaps where the color cells are
   dynamically allocated by individual X clients.

   With visuals that have a visual class of StaticColor and StaticGray
   (where the former is the case), the X server is asked to procure
   the pixel value of a color cell that contains the closest
   approximation of the color which Emacs wants.  On the other hand,
   when the visual class is DirectColor, PseudoColor, or GrayScale,
   where color cells are dynamically allocated by clients, Emacs asks
   the X server to allocate a color cell containing the desired color,
   and uses its pixel value.

   (If the color already exists, the X server returns an existing color
   cell, but increases its reference count, so it still has to be
   freed afterwards.)

   Otherwise, if no color could be allocated (due to the colormap
   being full), Emacs looks for a color cell inside the colormap
   closest to the desired color, and uses its pixel value instead.

   Since the capacity of a colormap is finite, X clients have to take
   special precautions in order to not allocate too many color cells
   that are never used.  Emacs allocates its color cells when a face
   is being realized or when a frame changes its foreground and
   background colors, and releases them alongside the face or frame.
   See calls to `unload_color' and `load_color' in xterm.c, xfaces.c
   and xfns.c for more details.

   The driving logic behind color allocation is in
   `x_alloc_nearest_color_1', while the optimization for TrueColor
   visuals is in `x_make_truecolor_pixel'.  Also see `x_query_colors`,
   which is used to determine the color values for given pixel
Po Lu's avatar
Po Lu committed
211 212

Po Lu's avatar
Po Lu committed
213 214 215 216
   In other window systems supported by Emacs, color allocation is
   handled by the window system itself, to whom Emacs simply passes 24
   (or 32-bit) RGB values.

Po Lu's avatar
Po Lu committed
217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271

   While X servers and client libraries tend to come with many
   extensions to the core X11R6 protocol, dependencies on anything
   other than the core X11R6 protocol and Xlib should be optional at
   both compile-time and runtime.  Emacs should also not crash
   regardless of what combination of X server and client-side features
   are present.  For example, if you are developing a feature that
   will need Xfixes, then add a test in configure.ac for the library
   at compile-time which defines `HAVE_XFIXES', like this:

     ### Use Xfixes (-lXfixes) if available
     if test "${HAVE_X11}" = "yes"; then
       if test $HAVE_XFIXES = no; then
	 # Test old way in case pkg-config doesn't have it (older machines).
	   [AC_CHECK_LIB(Xfixes, XFixesHideCursor, HAVE_XFIXES=yes)])
	 if test $HAVE_XFIXES = yes; then
       if test $HAVE_XFIXES = yes; then
	 AC_DEFINE(HAVE_XFIXES, 1, [Define to 1 if you have the Xfixes extension.])

  Then, make sure to adjust CFLAGS and LIBES in src/Makefile.in and
  add the new XFIXES_CFLAGS and XFIXES_LIBS variables to
  msdos/sed1v2.inp.  (The latter has to be adjusted for any new
  variables that are included in CFLAGS and LIBES even if the
  libraries are not used by the MS-DOS port.)

  Finally, add some fields in `struct x_display_info' which specify
  the major and minor versions of the extension, and whether or not to
  support them.  They (and their accessors) should be protected by the
  `HAVE_XFIXES' preprocessor conditional.  Then, these fields should
  be set in `x_term_init', and all Xfixes calls must be protected by
  not only the preprocessor conditional, but also by checks against
  those variables.


  Emacs supports being built with many different toolkits (and also no
  toolkit at all), which provide decorations such as menu bars and
  scroll bars, along with handy features like file panels, dialog
  boxes, font panels, and popup menus.  Those configurations can
  roughly be classified as belonging to one of three categories:

    - Using no toolkit at all.
    - Using the X Toolkit Intrinsics (Xt).
Po Lu's avatar
Po Lu committed
273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323
    - Using GTK.

  The no toolkit configuration is the simplest: no toolkit widgets are
  used, Emacs uses its own implementation of scroll bars, and the
  XMenu library that came with X11R2 and earlier versions of X is used
  for popup menus.  There is also no complicated window structure to
  speak of.

  The Xt configurations come in either the Lucid or Motif flavors.
  The former utilizes Emacs's own Xt-based Lucid widget library for
  menus, and Xaw (or derivatives such as neXTaw and Xaw3d) for dialog
  boxes and, optionally, scroll bars.  It does not support file
  panels.  The latter uses either Motif or LessTif for menu bars,
  popup menus, dialogs and file panels.

  The GTK configurations come in the GTK+ 2 or GTK 3 configurations,
  where the toolkit provides all the aforementioned decorations and
  features.  They work mostly the same, though GTK 3 has various small
  annoyances that complicate maintenance.

  All of those configurations have various special technicalities
  about event handling and the layout of windows inside a frame that
  must be kept in mind when writing X code which is run on all of

  The no toolkit configuration has no noteworthy aspects about the
  layout of windows inside a frame, since each frame has only one
  associated window aside from scroll bars.  However, in the Xt
  configurations, every widget is a separate window, and there are
  quite a few widgets.  The "outer widget", a widget of class
  ApplicationShell, is the top-level window of a frame.  Its window is
  accessed via the macro `FRAME_OUTER_WINDOW'.  The "edit widget", a
  widget class of EmacsFrame, is a child of the outer widget that
  controls the size of a frame as known to Emacs, and is the widget
  that Emacs draws to during display operations.  The "menu bar
  widget" is the widget holding the menu bar.

  Special care must be taken when performing operations on a frame.
  Properties that are used by the window manager, for example, must be
  set on the outer widget.  Drawing, on the other hand, must be done
  to the edit widget, and button press events on the menu bar widget
  must be redirected and not sent to Xt until the Lisp code is run to
  update the menu bar.

  The EmacsFrame widget is specific to Emacs and is implemented in
  widget.c.  See that file for more details.

  In the GTK configurations, GTK widgets do not necessarily correspond
  to X windows, since the toolkit might decide to keep only a
  client-side record of the widgets for performance reasons.

324 325
  Because the GtkFixed widget that holds the "edit area" might not
  correspond to an X window, drawing operations may be directly
Po Lu's avatar
Po Lu committed
326 327 328
  performed on the outer window, with special care taken to not
  overwrite the surrounding GTK widgets.  This also means that the
  only important window for most purposes is the outer window, which
  on GTK builds can usually be accessed using the macro
Po Lu's avatar
Po Lu committed
330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350

  How `handle_one_xevent' is called also depends on the configuration.
  Without a toolkit, Emacs performs all event processing by itself,
  running XPending and XNextEvent in a loop whenever there is input,
  passing the event to `handle_one_xevent'.

  When using Xt, the same is performed, but `handle_one_xevent' may
  also decide to call XtDispatchEvent on an event after Emacs finishes
  processing it.

  When using GTK, however, `handle_one_xevent' is called from an event
  filter installed on the GTK event loop.  Unless the event filter
  elects to drop the event, it will be passed to GTK right after
  leaving the event filter.

  Fortunately, `handle_one_xevent' is provided a `*finish' parameter
  that abstracts away all these details.  If it is `X_EVENT_DROP',
  then the event will not be dispatched to Xt or utilized by GTK.
  Code inside `handle_one_xevent' should thus avoid making assumptions
  about the event dispatch mechanism and use that parameter
351 352 353 354


355 356 357 358 359 360 361 362 363 364
  In the following explanations "frame size" refers to the "native
  size" of a frame as reported by the (frame.h) macros
  FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT.  These specify the size of
  a frame as the values passed to/received from a toolkit and the
  window manager.  The "text size" Emacs Lisp code uses in functions
  like 'set-frame-size' or sees in the ‘width’ and 'height' frame
  parameters is only loosely related to the native size.  The
  necessary translations are provided by the macros
365 366 367 368

  Lisp functions may ask for resizing a frame either explicitly, using
  one of the interfaces provided for that purpose like, for example,
369 370 371 372 373 374 375 376 377 378 379 380 381 382 383
  'set-frame-size' or changing the 'height' or 'width' parameter of
  that frame, or implicitly, for example, by turning off/on or
  changing the width of fringes or scroll bars for that frame.  Any
  such request passes through the routine 'adjust_frame_size' (in
  frame.c) which decides, among others, whether the native frame size
  would really change and whether it is allowed to change it at that
  moment.  Only if 'adjust_frame_size' decides that the corresponding
  terminal's 'set_window_size_hook' may be run, it will dispatch
  execution to the appropriate function which, for X builds, is
  'x_set_window_size' in this file.

  For GTK builds, 'x_set_window_size' calls 'xg_frame_set_char_size'
  in gtkutil.c if the frame has an edit widget and
  'x_set_window_size_1' in this file otherwise.  For non-GTK builds,
  'x_set_window_size' always calls 'x_set_window_size_1' directly.
384 385 386 387 388 389 390 391 392 393

  'xg_frame_set_char_size' calls the GTK function 'gtk_window_resize'
  for the frame's outer widget; x_set_window_size_1 calls the Xlib
  function 'XResizeWindow' instead.  In either case, if Emacs thinks
  that the frame is visible, it will wait for a ConfigureNotify event
  (see below) to occur within a timeout of 'x-wait-for-event-timeout'
  (the default is 0.1 seconds).  If Emacs thinks that the frame is not
  visible, it calls 'adjust_frame_size' to run 'resize_frame_windows'
  (see below) and hopes for the best.

394 395 396 397
  Note that if Emacs receives a ConfigureEvent in response to an
  earlier resize request, the sizes specified by that event are not
  necessarily the sizes Emacs requested.  Window manager and toolkit
  may override any of the requested sizes for their own reasons.

399 400 401 402 403 404 405 406
  On X, size notifications are received as ConfigureNotify events.
  The expected reaction to such an event on the Emacs side is to
  resize all Emacs windows that are on the frame referred to by the
  event.  Since resizing Emacs windows and redisplaying their buffers
  is a costly operation, Emacs may collapse several subsequent
  ConfigureNotify events into one to avoid that Emacs falls behind in
  user interactions like resizing a frame by dragging one of its
  borders with the mouse.
407 408 409

  Each ConfigureEvent event specifies a window, a width and a height.
  The event loop uses 'x_top_window_to_frame' to associate the window
410 411 412 413 414 415 416 417
  with its frame.  Once the frame has been identified, on GTK the
  event is dispatched to 'xg_frame_resized'.  On Motif/Lucid
  'x_window' has installed 'EmacsFrameResize' as the routine that
  handles resize events.  In either case, these routines end up
  calling the function 'change_frame_size' in dispnew.c.  On
  non-toolkit builds the effect is to call 'change_frame_size'
  directly from the event loop.  In either case, the value true is
  passed as the DELAY argument.
418 419 420 421 422 423 424 425 426 427 428 429

  'change_frame_size' is the central function to decide whether it is
  safe to process a resize request immediately or it has to be delayed
  (usually because its DELAY argument is true).  Since resizing a
  frame's windows may run arbitrary Lisp code, Emacs cannot generally
  process resize requests during redisplay and therefore has to queue
  them.  If processing the event must be delayed, the new sizes (that
  is, the ones requested by the ConfigureEvent) are stored in the
  new_width and new_height slots of the respective frame structure,
  possibly replacing ones that have been stored there upon the receipt
  of a preceding ConfigureEvent.

430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453
  Delayed size changes are applied eventually upon calls of the
  function 'do_pending_window_change' (in dispnew.c) which is called
  by the redisplay code at suitable spots where it's safe to change
  sizes.  'do_pending_window_change' calls 'change_frame_size' with
  its DELAY argument false in the hope that it is now safe to call the
  function 'resize_frame_windows' (in window.c) which is in charge of
  adjusting the sizes of all Emacs windows on the frame accordingly.
  Note that if 'resize_frame_windows' decides that the windows of a
  frame do not fit into the constraints set up by the new frame sizes,
  it will resize the windows to some minimum sizes with the effect
  that parts of the frame at the right and bottom will appear clipped

  In addition to explicitly passing width and height values in
  functions like 'gtk_window_resize' or 'XResizeWindow', Emacs also
  sets window manager size hints - a more implicit form of asking for
  the size Emacs would like its frames to assume.  Some of these hints
  only restate the size and the position explicitly requested for a
  frame.  Another hint specifies the increments in which the window
  manager should resize a frame to - either set to the default
  character size of a frame or to one pixel for a non-nil value of
  'frame-resize-pixelwise'.  See the function 'x_wm_set_size_hint' -
  in gtkutil.c for GTK and in this file for other builds - for the
454 455 456 457 458 459 460 461

  We have not discussed here a number of special issues like, for
  example, how to handle size requests and notifications for maximized
  and fullscreen frames or how to resize child frames.  Some of these
  require special treatment depending on the desktop or window manager

  One thing that might come handy when investigating problems wrt
462 463
  resizing frames is the variable 'frame-size-history'.  Setting this
  to a non-nil value, will cause Emacs to start recording frame size
464 465 466 467
  adjustments, usually specified by the function that asked for an
  adjustment, a sizes part that records the old and new values of the
  frame's width and height and maybe some additional information.  The
  internal function `frame--size-history' can then be used to display
468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510
  the value of this variable in a more readable form.


  The X window system operates asynchronously.  That is to say, the
  window manager and X server might think a window has been resized
  before Emacs has a chance to process the ConfigureNotify event that
  was sent.

  When a compositing manager is present, and the X server and Emacs
  both support the X synchronization extension, the semi-standard
  frame synchronization protocol can be used to notify the compositing
  manager of when Emacs has actually finished redisplaying the
  contents of a frame after a resize.  The compositing manager will
  customarily then postpone displaying the contents of the frame until
  the redisplay is complete.

  Emacs announces support for this protocol by creating an X
  server-side counter object, and setting it as the
  `_NET_WM_SYNC_REQUEST_COUNTER' property of the frame's top-level
  window.  The window manager then initiates the synchronized resize
  process by sending Emacs a ClientMessage event before the
  ConfigureNotify event where:

    type = ClientMessage
    window = the respective client window
    message_type = WM_PROTOCOLS
    format = 32
    data.l[0] = _NET_WM_SYNC_REQUEST
    data.l[1] = timestamp
    data.l[2] = low 32 bits of a provided frame counter value
    data.l[3] = high 32 bits of a provided frame counter value
    data.l[4] = 1 if the the extended frame counter should be updated,
    otherwise 0

  Upon receiving such an event, Emacs constructs and saves a counter
  value from the provided low and high 32 bits.  Then, when the
  display engine tells us that a frame has been completely updated
  (presumably because of a redisplay caused by a ConfigureNotify
  event), we set the counter to the saved value, telling the
  compositing manager that the contents of the window now accurately
  reflect the new size.  The compositing manager will then display the
  contents of the window, and the window manager might also postpone
Po Lu's avatar
Po Lu committed
511 512 513 514 515 516 517 518 519 520 521 522
  updating the window decorations until this moment.


  Drag and drop in Emacs is implemented in two ways, depending on
  which side initiated the drag-and-drop operation.  When another X
  client initiates a drag, and the user drops something on Emacs, a
  `drag-n-drop-event' is sent with the contents of the ClientMessage,
  and further processing (i.e. retrieving selection contents and
  replying to the initiating client) is performed from Lisp inside

523 524 525
  However, dragging contents from Emacs is implemented almost entirely
  in C.  X Windows has several competing drag-and-drop protocols, of
  which Emacs supports two on the C level: the XDND protocol (see
Po Lu's avatar
Po Lu committed
526 527 528 529 530 531
  https://freedesktop.org/wiki/Specifications/XDND) and the Motif drag
  and drop protocols.  These protocols are based on the initiator
  owning a special selection, specifying an action the recipient
  should perform, grabbing the mouse, and sending various different
  client messages to the toplevel window underneath the mouse as it
  moves, or when buttons are released.
Po Lu's avatar
Po Lu committed
532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547

  The Lisp interface to drag-and-drop is synchronous, and involves
  running a nested event loop with some global state until the drag
  finishes.  When the mouse moves, Emacs looks up the toplevel window
  underneath the pointer (the target window) either using a cache
  provided by window managers that support the
  _NET_WM_CLIENT_LIST_STACKING root window property, or by calling
  XTranslateCoordinates in a loop until a toplevel window is found,
  and sends various entry, exit, or motion events to the window
  containing a list of targets the special selection can be converted
  to, and the chosen action that the recipient should perform.  The
  recipient can then send messages in reply detailing the action it
  has actually chosen to perform.  Finally, when the mouse buttons are
  released over the recipient window, Emacs sends a "drop" message to
  the target window, waits for a reply, and returns the action
  selected by the recipient to the Lisp code that initiated the
548 549 550 551 552 553 554 555 556 557
  drag-and-drop operation.

  When a drop happens on a window not supporting any protocol
  implemented on the C level, the function inside
  `x-dnd-unsupported-drop-function' is called with some parameters of
  the drop.  If it returns non-nil, then Emacs tries to simulate a
  drop happening with the primary selection and synthetic button
  events (see `x_dnd_do_unsupported_drop').  That function implements
  the OffiX drag-and-drop protocol by default.  See
  `x-dnd-handle-unsupported-drop' in `x-dnd.el' for more details.  */

#include <config.h>
Paul Eggert's avatar
Paul Eggert committed
#include <stdlib.h>
#include <math.h>
#include <signal.h>

Jim Blandy's avatar
Jim Blandy committed
#include "lisp.h"
#include "blockinput.h"
#include "sysstdio.h"

Jim Blandy's avatar
Jim Blandy committed
568 569 570
/* This may include sys/types.h, and that somehow loses
   if this is not done before the other system files.  */
#include "xterm.h"
#include <X11/cursorfont.h>
Jim Blandy's avatar
Jim Blandy committed

573 574
#ifdef USE_XCB
#include <xcb/xproto.h>
Po Lu's avatar
Po Lu committed
575 576
#include <xcb/xcb.h>
#include <xcb/xcb_aux.h>
577 578

579 580 581 582 583
/* If we have Xfixes extension, use it for pointer blanking.  */
#include <X11/extensions/Xfixes.h>

584 585 586 587
#ifdef HAVE_XDBE
#include <X11/extensions/Xdbe.h>

588 589 590 591
#include <X11/extensions/XInput2.h>

592 593 594 595
#include <X11/extensions/Xrandr.h>

596 597 598 599
#include <X11/extensions/sync.h>

600 601 602 603
#include <X11/extensions/Xinerama.h>

604 605 606 607
#include <X11/extensions/Xcomposite.h>

608 609 610 611
#include <X11/extensions/shape.h>

612 613 614 615
#include <xcb/shape.h>

Jim Blandy's avatar
Jim Blandy committed
616 617 618 619
/* Load sys/types.h if not already loaded.
   In some systems loading it twice is suicidal.  */
#ifndef makedev
#include <sys/types.h>
#endif /* makedev */
Jim Blandy's avatar
Jim Blandy committed
621 622 623

#include <sys/ioctl.h>

Jim Blandy's avatar
Jim Blandy committed
#include "systime.h"
Jim Blandy's avatar
Jim Blandy committed
625 626 627 628

#include <fcntl.h>
#include <errno.h>
#include <sys/stat.h>
#include <flexmember.h>
Po Lu's avatar
Po Lu committed
#include <c-ctype.h>
#include <byteswap.h>
Po Lu's avatar
Po Lu committed

Kenichi Handa's avatar
Kenichi Handa committed
#include "character.h"
Kenichi Handa's avatar
Kenichi Handa committed
#include "coding.h"
#include "composite.h"
#include "frame.h"
Jim Blandy's avatar
Jim Blandy committed
#include "dispextern.h"
Paul Eggert's avatar
Paul Eggert committed
#include "xwidget.h"
#include "fontset.h"
Jim Blandy's avatar
Jim Blandy committed
640 641 642
#include "termhooks.h"
#include "termopts.h"
#include "termchar.h"
#include "emacs-icon.h"
Jim Blandy's avatar
Jim Blandy committed
#include "buffer.h"
#include "window.h"
Richard M. Stallman's avatar
Richard M. Stallman committed
#include "keyboard.h"
Gerd Moellmann's avatar
Gerd Moellmann committed
#include "atimer.h"
#include "font.h"
#include "xsettings.h"
#include "sysselect.h"
#include "menu.h"
Daniel Colascione's avatar
Daniel Colascione committed
#include "pdumper.h"
Jim Blandy's avatar
Jim Blandy committed

654 655
#include <X11/Shell.h>
#include <X11/ShellP.h>
657 658

659 660
#include <unistd.h>

Jan Djärv's avatar
Jan Djärv committed
661 662
#ifdef USE_GTK
#include "gtkutil.h"
Jan Djärv's avatar
Jan Djärv committed
663 664 665
#ifdef HAVE_GTK3
#include <X11/Xproto.h>
Jan Djärv's avatar
Jan Djärv committed
666 667

#if defined (USE_LUCID) || defined (USE_MOTIF)
#include "../lwlib/xlwmenu.h"
Jan Djärv's avatar
Jan Djärv committed

672 673 674 675
#include <cairo-xlib.h>

676 677
#ifdef USE_MOTIF
#include <Xm/Xm.h>
Po Lu's avatar
Po Lu committed
#include <Xm/CascadeB.h>
679 680

Jan Djärv's avatar
Jan Djärv committed
682 683 684 685 686

/* Include toolkit specific headers for the scroll bar widget.  */
#if defined USE_MOTIF
#include <Xm/ScrollBar.h>
687 688 689
#else /* !USE_MOTIF i.e. use Xaw */

#ifdef HAVE_XAW3D
690 691
#include <X11/Xaw3d/Simple.h>
#include <X11/Xaw3d/Scrollbar.h>
#include <X11/Xaw3d/ThreeD.h>
693 694 695 696 697 698 699 700
#else /* !HAVE_XAW3D */
#include <X11/Xaw/Simple.h>
#include <X11/Xaw/Scrollbar.h>
#endif /* !HAVE_XAW3D */
#ifndef XtNpickTop
#define XtNpickTop "pickTop"
#endif /* !XtNpickTop */
#endif /* !USE_MOTIF */
701 702

703 704
#endif /* USE_X_TOOLKIT */

Karl Heuer's avatar
Karl Heuer committed
#include "widget.h"
707 708 709 710 711
#ifndef XtNinitialState
#define XtNinitialState "initialState"

712 713 714 715
#ifdef USE_GTK
#include <xgselect.h>

716 717
#include "bitmaps/gray.xbm"

718 719 720 721
#ifdef HAVE_XKB
#include <X11/XKBlib.h>

722 723 724 725
#if defined USE_XCB && defined USE_CAIRO_XCB

Dave Love's avatar
Dave Love committed
/* Default to using XIM if available.  */
#ifdef USE_XIM
bool use_xim = true;
bool use_xim = false;  /* configure --without-xim */
731 732

733 734 735 736 737 738

739 740 741 742 743 744 745 746 747 748 749
#ifdef USE_GTK
/* GTK can't tolerate a call to `handle_interrupt' inside an event
   signal handler, but we have to store input events inside the
   handler for native input to work.

   This acts as a `hold_quit', and it is stored in the keyboard buffer
   (thereby causing the call to `handle_interrupt') after the GTK
   signal handler exits and control returns to XTread_socket.  */
struct input_event xg_pending_quit_event = { .kind = NO_EVENT };

750 751 752
/* Non-zero means that a HELP_EVENT has been generated since Emacs
   start.  */

static bool any_help_event_p;
754 755 756 757

/* This is a chain of structures for all the X displays currently in
   use.  */

struct x_display_info *x_display_list;
Jim Blandy's avatar
Jim Blandy committed


762 763
/* The application context for Xt use.  */
XtAppContext Xt_app_con;
static String Xt_default_resources[] = {0};

Gerd Moellmann's avatar
Gerd Moellmann committed
/* Non-zero means user is interacting with a toolkit scroll bar.  */
static bool toolkit_scroll_bar_interaction;
Gerd Moellmann's avatar
Gerd Moellmann committed

#endif /* USE_X_TOOLKIT */
Jim Blandy's avatar
Jim Blandy committed

Kenichi Handa's avatar
Kenichi Handa committed
771 772 773 774
/* Non-zero timeout value means ignore next mouse click if it arrives
   before that timeout elapses (i.e. as part of the same sequence of
   events resulting from clicking on a frame to select it).  */

static Time ignore_next_mouse_click_timeout;
Kenichi Handa's avatar
Kenichi Handa committed

777 778 779 780
/* The display that ignore_next_mouse_click_timeout applies to.  */

static struct x_display_info *mouse_click_timeout_display;

/* Used locally within XTread_socket.  */

static int x_noop_count;
Jim Blandy's avatar
Jim Blandy committed

785 786 787 788 789
#ifdef USE_GTK
/* The name of the Emacs icon file.  */
static Lisp_Object xg_default_icon_file;

Po Lu's avatar
Po Lu committed
#ifdef HAVE_X_I18N
791 792
/* Some functions take this as char *, not const char *.  */
static char emacs_class[] = EMACS_CLASS;
Po Lu's avatar
Po Lu committed

795 796 797 798 799 800
#ifdef USE_GTK
static int current_count;
static int current_finish;
static struct input_event *current_hold_quit;

801 802 803 804
/* Queue selection requests in `pending_selection_requests' if more
   than 0.  */
static int x_use_pending_selection_requests;

805 806 807 808
/* Like `next_kbd_event', but for use in X code.  */
#define X_NEXT_KBD_EVENT(ptr) \
  ((ptr) == kbd_buffer + KBD_BUFFER_SIZE - 1 ? kbd_buffer : (ptr) + 1)

809 810
static void x_push_selection_request (struct selection_input_event *);

811 812 813
/* Defer selection requests.  Between this and
   x_release_selection_requests, any selection requests can be
   processed by calling `x_handle_pending_selection_requests'.
814 815 816 817

   Also run through and queue all the selection events already in the
   keyboard buffer.  */
818 819
x_defer_selection_requests (void)
  union buffered_input_event *event;
  bool between;

  between = false;

  block_input ();
826 827 828 829 830 831 832 833 834 835 836 837 838
  if (!x_use_pending_selection_requests)
      event = kbd_fetch_ptr;

      while (event != kbd_store_ptr)
	  if (event->ie.kind == SELECTION_REQUEST_EVENT
	      || event->ie.kind == SELECTION_CLEAR_EVENT)
	      x_push_selection_request (&event->sie);

	      /* Mark this selection event as invalid.   */
	      SELECTION_EVENT_DPYINFO (&event->sie) = NULL;
839 840 841 842 843 844

	      /* Move the kbd_fetch_ptr along if doing so would not
		 result in any other events being skipped.  This
		 avoids exhausting the keyboard buffer with some
		 over-enthusiastic clipboard managers.  */
	      if (!between)
		kbd_fetch_ptr = X_NEXT_KBD_EVENT (event);
847 848
	    between = true;

	  event = X_NEXT_KBD_EVENT (event);
851 852 853

  unblock_input ();
856 857 858 859 860 861 862 863

static void
x_release_selection_requests (void)

864 865 866 867 868 869 870 871 872
x_release_selection_requests_and_flush (void)
  x_release_selection_requests ();

  if (!x_use_pending_selection_requests)
    x_handle_pending_selection_requests ();

873 874 875 876 877 878 879 880 881 882 883 884 885 886 887
struct x_selection_request_event
  /* The selection request event.  */
  struct selection_input_event se;

  /* The next unprocessed selection request event.  */
  struct x_selection_request_event *next;

/* Chain of unprocessed selection request events.  Used to handle
   selection requests inside long-lasting modal event loops, such as
   the drag-and-drop loop.  */

struct x_selection_request_event *pending_selection_requests;

888 889 890 891 892
/* Compare two request serials A and B with OP, handling
   wraparound.  */
#define X_COMPARE_SERIALS(a, op ,b) \
  (((long) (a) - (long) (b)) op 0)

893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935
struct x_atom_ref
  /* Atom name.  */
  const char *name;

  /* Offset of atom in the display info structure.  */
  int offset;

/* List of all atoms that should be interned when connecting to a
   display.  */
static const struct x_atom_ref x_atom_refs[] =
#define ATOM_REFS_INIT(string, member)				\
    { string, offsetof (struct x_display_info, member) },
    ATOM_REFS_INIT ("WM_PROTOCOLS", Xatom_wm_protocols)
    ATOM_REFS_INIT ("WM_TAKE_FOCUS", Xatom_wm_take_focus)
    ATOM_REFS_INIT ("WM_SAVE_YOURSELF", Xatom_wm_save_yourself)
    ATOM_REFS_INIT ("WM_DELETE_WINDOW", Xatom_wm_delete_window)
    ATOM_REFS_INIT ("WM_CHANGE_STATE", Xatom_wm_change_state)
    ATOM_REFS_INIT ("WM_STATE", Xatom_wm_state)
    ATOM_REFS_INIT ("WM_CONFIGURE_DENIED", Xatom_wm_configure_denied)
    ATOM_REFS_INIT ("WM_MOVED", Xatom_wm_window_moved)
    ATOM_REFS_INIT ("WM_CLIENT_LEADER", Xatom_wm_client_leader)
    ATOM_REFS_INIT ("WM_TRANSIENT_FOR", Xatom_wm_transient_for)
    ATOM_REFS_INIT ("Editres", Xatom_editres)
937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022
    /* For properties of font.  */
    /* Ghostscript support.  */
    ATOM_REFS_INIT ("SCROLLBAR", Xatom_Scrollbar)
    ATOM_REFS_INIT ("HORIZONTAL_SCROLLBAR", Xatom_Horizontal_Scrollbar)
    /* EWMH */
    ATOM_REFS_INIT ("_NET_WM_STATE", Xatom_net_wm_state)
    ATOM_REFS_INIT ("_NET_WM_STATE_FULLSCREEN", Xatom_net_wm_state_fullscreen)
    ATOM_REFS_INIT ("_NET_WM_STATE_STICKY", Xatom_net_wm_state_sticky)
    ATOM_REFS_INIT ("_NET_WM_STATE_SHADED", Xatom_net_wm_state_shaded)
    ATOM_REFS_INIT ("_NET_WM_STATE_HIDDEN", Xatom_net_wm_state_hidden)
    ATOM_REFS_INIT ("_NET_WM_WINDOW_TYPE", Xatom_net_window_type)
    ATOM_REFS_INIT ("_NET_WM_ICON_NAME", Xatom_net_wm_icon_name)
    ATOM_REFS_INIT ("_NET_WM_NAME", Xatom_net_wm_name)
    ATOM_REFS_INIT ("_NET_SUPPORTED",  Xatom_net_supported)
    ATOM_REFS_INIT ("_NET_SUPPORTING_WM_CHECK", Xatom_net_supporting_wm_check)
    ATOM_REFS_INIT ("_NET_WM_WINDOW_OPACITY", Xatom_net_wm_window_opacity)
    ATOM_REFS_INIT ("_NET_ACTIVE_WINDOW", Xatom_net_active_window)
    ATOM_REFS_INIT ("_NET_FRAME_EXTENTS", Xatom_net_frame_extents)
    ATOM_REFS_INIT ("_NET_CURRENT_DESKTOP", Xatom_net_current_desktop)
    ATOM_REFS_INIT ("_NET_WORKAREA", Xatom_net_workarea)
    ATOM_REFS_INIT ("_NET_WM_SYNC_REQUEST", Xatom_net_wm_sync_request)
    ATOM_REFS_INIT ("_NET_WM_SYNC_REQUEST_COUNTER", Xatom_net_wm_sync_request_counter)
    ATOM_REFS_INIT ("_NET_WM_FRAME_DRAWN", Xatom_net_wm_frame_drawn)
    ATOM_REFS_INIT ("_NET_WM_USER_TIME", Xatom_net_wm_user_time)
    ATOM_REFS_INIT ("_NET_WM_USER_TIME_WINDOW", Xatom_net_wm_user_time_window)
    ATOM_REFS_INIT ("_NET_CLIENT_LIST_STACKING", Xatom_net_client_list_stacking)
    /* Session management */
    ATOM_REFS_INIT ("_XSETTINGS_SETTINGS", Xatom_xsettings_prop)
    ATOM_REFS_INIT ("MANAGER", Xatom_xsettings_mgr)
    ATOM_REFS_INIT ("_NET_WM_STATE_SKIP_TASKBAR", Xatom_net_wm_state_skip_taskbar)
    ATOM_REFS_INIT ("_NET_WM_STATE_ABOVE", Xatom_net_wm_state_above)
    ATOM_REFS_INIT ("_NET_WM_STATE_BELOW", Xatom_net_wm_state_below)
    ATOM_REFS_INIT ("_NET_WM_OPAQUE_REGION", Xatom_net_wm_opaque_region)
    ATOM_REFS_INIT ("_NET_WM_PING", Xatom_net_wm_ping)
    ATOM_REFS_INIT ("_NET_WM_PID", Xatom_net_wm_pid)
#ifdef HAVE_XKB
    ATOM_REFS_INIT ("Meta", Xatom_Meta)
    ATOM_REFS_INIT ("Super", Xatom_Super)
    ATOM_REFS_INIT ("Hyper", Xatom_Hyper)
    ATOM_REFS_INIT ("ShiftLock", Xatom_ShiftLock)
    ATOM_REFS_INIT ("Alt", Xatom_Alt)
    /* DND source.  */
    ATOM_REFS_INIT ("XdndAware", Xatom_XdndAware)
    ATOM_REFS_INIT ("XdndSelection", Xatom_XdndSelection)
    ATOM_REFS_INIT ("XdndTypeList", Xatom_XdndTypeList)
    ATOM_REFS_INIT ("XdndActionCopy", Xatom_XdndActionCopy)
    ATOM_REFS_INIT ("XdndActionMove", Xatom_XdndActionMove)
    ATOM_REFS_INIT ("XdndActionLink", Xatom_XdndActionLink)
    ATOM_REFS_INIT ("XdndActionAsk", Xatom_XdndActionAsk)
    ATOM_REFS_INIT ("XdndActionPrivate", Xatom_XdndActionPrivate)
    ATOM_REFS_INIT ("XdndActionList", Xatom_XdndActionList)
    ATOM_REFS_INIT ("XdndActionDescription", Xatom_XdndActionDescription)
    ATOM_REFS_INIT ("XdndProxy", Xatom_XdndProxy)
    ATOM_REFS_INIT ("XdndEnter", Xatom_XdndEnter)
    ATOM_REFS_INIT ("XdndPosition", Xatom_XdndPosition)
    ATOM_REFS_INIT ("XdndStatus", Xatom_XdndStatus)
    ATOM_REFS_INIT ("XdndLeave", Xatom_XdndLeave)
    ATOM_REFS_INIT ("XdndDrop", Xatom_XdndDrop)
    ATOM_REFS_INIT ("XdndFinished", Xatom_XdndFinished)
    /* Motif drop protocol support.  */
1023 1024 1025
    /* Old OffiX (a.k.a. old KDE) drop protocol support.  */
    ATOM_REFS_INIT ("DndProtocol", Xatom_DndProtocol)
1026 1027

1028 1029 1030 1031 1032 1033 1034

Andreas Schwab's avatar
Andreas Schwab committed
1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056
enum xembed_info
    XEMBED_MAPPED = 1 << 0

enum xembed_message
    XEMBED_REQUEST_FOCUS          = 3,
    XEMBED_FOCUS_IN               = 4,
    XEMBED_FOCUS_OUT              = 5,
    XEMBED_FOCUS_NEXT             = 6,
    XEMBED_FOCUS_PREV             = 7,

    XEMBED_MODALITY_ON            = 10,
    XEMBED_MODALITY_OFF           = 11,

static bool x_alloc_nearest_color_1 (Display *, Colormap, XColor *);
1059 1060
static void x_raise_frame (struct frame *);
static void x_lower_frame (struct frame *);
1061 1062 1063 1064
static int x_io_error_quitter (Display *);
static struct terminal *x_create_terminal (struct x_display_info *);
static void x_frame_rehighlight (struct x_display_info *);

Joakim Verona's avatar
Joakim Verona committed
1065 1066
static void x_clip_to_row (struct window *, struct glyph_row *,
			   enum glyph_row_area, GC);
static struct scroll_bar *x_window_to_scroll_bar (Display *, Window, int);
static struct frame *x_window_to_frame (struct x_display_info *, int);
1069 1070 1071
static void x_scroll_bar_report_motion (struct frame **, Lisp_Object *,
                                        enum scroll_bar_part *,
                                        Lisp_Object *, Lisp_Object *,
                                        Time *);
1073 1074 1075 1076
static void x_horizontal_scroll_bar_report_motion (struct frame **, Lisp_Object *,
						   enum scroll_bar_part *,
						   Lisp_Object *, Lisp_Object *,
						   Time *);
Paul Eggert's avatar
Paul Eggert committed
static bool x_handle_net_wm_state (struct frame *, const XPropertyEvent *);
1078 1079
static void x_check_fullscreen (struct frame *);
static void x_check_expected_move (struct frame *, int, int);
Paul Eggert's avatar
Paul Eggert committed
static void x_sync_with_move (struct frame *, int, int, bool);
#ifndef HAVE_XINPUT2
static int handle_one_xevent (struct x_display_info *,
			      const XEvent *, int *,
			      struct input_event *);
1085 1086 1087 1088 1089
static int handle_one_xevent (struct x_display_info *,
			      XEvent *, int *,
			      struct input_event *);
#if ! (defined USE_X_TOOLKIT || defined USE_MOTIF) && defined USE_GTK
1091 1092 1093
static int x_dispatch_event (XEvent *, Display *);
static void x_wm_set_window_state (struct frame *, int);
static void x_wm_set_icon_pixmap (struct frame *, ptrdiff_t);
static void x_initialize (void);
Jan Djärv's avatar
Jan Djärv committed

Po Lu's avatar
Po Lu committed
static bool x_get_current_wm_state (struct frame *, Window, int *, bool *, bool *);
static void x_update_opaque_region (struct frame *, XEvent *);

Po Lu's avatar
Po Lu committed
1100 1101 1102 1103
#if !defined USE_TOOLKIT_SCROLL_BARS && defined HAVE_XDBE
static void x_scroll_bar_end_update (struct x_display_info *, struct scroll_bar *);

1104 1105 1106 1107
#ifdef HAVE_X_I18N
static int x_filter_event (struct x_display_info *, XEvent *);

1108 1109 1110 1111
static struct frame *x_tooltip_window_to_frame (struct x_display_info *,
						Window, bool *);
static Window x_get_window_below (Display *, Window, int, int, int *, int *);

1112 1113 1114
/* Global state maintained during a drag-and-drop operation.  */

/* Flag that indicates if a drag-and-drop operation is in progress.  */
1115 1116
bool x_dnd_in_progress;

1117 1118 1119 1120
/* Number that indicates the last "generation" of
unsigned x_dnd_unsupported_event_level;

1121 1122
/* The frame where the drag-and-drop operation originated.  */
struct frame *x_dnd_frame;

1124 1125 1126 1127 1128
/* That frame, but set when x_dnd_waiting_for_finish is true.  Used to
   prevent the frame from being deleted inside selection handlers and
   other callbacks.  */
struct frame *x_dnd_finish_frame;

1129 1130 1131 1132
/* Flag that indicates if a drag-and-drop operation is no longer in
   progress, but the nested event loop should continue to run, because
   handle_one_xevent is waiting for the drop target to return some
   important information.  */
bool x_dnd_waiting_for_finish;

1135 1136 1137 1138 1139 1140 1141
/* Whether or not to move the tooltip along with the mouse pointer
   during drag-and-drop.  */
static bool x_dnd_update_tooltip;

/* Monitor attribute list used for updating the tooltip position.  */
static Lisp_Object x_dnd_monitors;

Po Lu's avatar
Po Lu committed
1142 1143 1144 1145
/* The display the drop target that is supposed to send information is
   on.  */
static Display *x_dnd_finish_display;

1146 1147 1148 1149 1150 1151 1152 1153 1154
/* State of the Motif drop operation.

   0 means nothing has happened, i.e. the event loop should not wait
   for the receiver to send any data.  1 means an XmDROP_START message
   was sent to the target, but no response has yet been received.  2
   means a response to our XmDROP_START message was received and the
   target accepted the drop, so Emacs should start waiting for the
   drop target to convert one of the special selections
static int x_dnd_waiting_for_motif_finish;

1157 1158 1159 1160
/* The display the Motif drag receiver will send response data
   from.  */
struct x_display_info *x_dnd_waiting_for_motif_finish_display;

1161 1162 1163 1164
/* Whether or not F1 was pressed during the drag-and-drop operation.

   Motif programs rely on this to decide whether or not help
   information about the drop site should be displayed.  */
Po Lu's avatar
Po Lu committed
static bool x_dnd_xm_use_help;
1166 1167

/* Whether or not Motif drag initiator info was set up.  */
Po Lu's avatar
Po Lu committed
static bool x_dnd_motif_setup_p;

Po Lu's avatar
Po Lu committed
1170 1171 1172
/* The Motif drag atom used during the drag-and-drop operation.  */
static Atom x_dnd_motif_atom;

1173 1174
/* The target window we are waiting for an XdndFinished message
   from.  */
static Window x_dnd_pending_finish_target;
1176 1177

/* The protocol version of that target window.  */
static int x_dnd_waiting_for_finish_proto;
1179 1180 1181

/* Whether or not it is OK for something to be dropped on the frame
   where the drag-and-drop operation originated.  */
static bool x_dnd_allow_current_frame;

1184 1185 1186 1187
/* Whether or not the `XdndTypeList' property has already been set on
   the drag frame.  */
static bool x_dnd_init_type_lists;

1188 1189 1190 1191
/* Whether or not to return a frame from `x_dnd_begin_drag_and_drop'.

   0 means to do nothing.  1 means to wait for the mouse to first exit
   `x_dnd_frame'.  2 means to wait for the mouse to move onto a frame,
   and 3 means to return `x_dnd_return_frame_object'.  */
static int x_dnd_return_frame;
1194 1195 1196

/* The frame that should be returned by
   `x_dnd_begin_drag_and_drop'.  */
1197 1198
static struct frame *x_dnd_return_frame_object;

1199 1200 1201
/* The last drop target window the mouse pointer moved over.  This can
   be different from `x_dnd_last_seen_toplevel' if that window had an
   XdndProxy.  */
static Window x_dnd_last_seen_window;

1204 1205 1206
/* The last toplevel the mouse pointer moved over.  */
static Window x_dnd_last_seen_toplevel;

1207 1208
/* The window where the drop happened.  Normally None, but it is set
   when something is actually dropped.  */
static Window x_dnd_end_window;
1210 1211 1212

/* The XDND protocol version of `x_dnd_last_seen_window'.  -1 means it
   did not support XDND.  */
static int x_dnd_last_protocol_version;

1215 1216 1217 1218
/* Whether or not the last seen window is actually one of our
   frames.  */
static bool x_dnd_last_window_is_frame;

1219 1220 1221 1222 1223 1224
/* The Motif drag and drop protocol style of `x_dnd_last_seen_window'.
   XM_DRAG_STYLE_NONE means the window does not support the Motif drag
   or drop protocol.  XM_DRAG_STYLE_DROP_ONLY means the window does
   not respond to any drag protocol messages, so only drops should be
   sent.  Any other value means that the window supports both the drag
   and drop protocols.  */
Po Lu's avatar
Po Lu committed
static int x_dnd_last_motif_style;
1226 1227 1228

/* The timestamp where Emacs last acquired ownership of the
   `XdndSelection' selection.  */
1229 1230
static Time x_dnd_selection_timestamp;

/* The drop target window to which the rectangle below applies.  */
static Window x_dnd_mouse_rect_target;
1233 1234 1235

/* A rectangle where XDND position messages should not be sent to the
   drop target if the mouse pointer lies within.  */
static XRectangle x_dnd_mouse_rect;
1237 1238 1239 1240 1241 1242 1243

/* The action the drop target actually chose to perform.

   Under XDND, this is set upon receiving the XdndFinished or
   XdndStatus messages from the drop target.

   Under Motif, this is changed upon receiving a XmDROP_START message
1244 1245 1246 1247
   in reply to our own.

   When dropping on a target that doesn't support any drag-and-drop
   protocol, this is set to the atom XdndActionPrivate.  */
static Atom x_dnd_action;

1250 1251 1252 1253
/* The symbol to return from `x-begin-drag' if non-nil.  Takes
   precedence over `x_dnd_action`.  */
static Lisp_Object x_dnd_action_symbol;

1254 1255 1256
/* The action we want the drop target to perform.  The drop target may
   elect to perform some different action, which is guaranteed to be
   in `x_dnd_action' upon completion of a drop.  */
1257 1258
static Atom x_dnd_wanted_action;

1259 1260 1261 1262 1263 1264 1265 1266
/* The set of optional actions available to a Motif drop target
   computed at the start of the drag-and-drop operation.  */
static uint8_t x_dnd_motif_operations;

/* The preferred optional action out of that set.  Only takes effect
   if `x_dnd_action' is XdndAsk.  */
static uint8_t x_dnd_first_motif_operation;

/* Array of selection targets available to the drop target.  */
static Atom *x_dnd_targets;
1269 1270

/* The number of elements in that array.  */
static int x_dnd_n_targets;
1272 1273 1274 1275 1276

/* The old window attributes of the root window before the
   drag-and-drop operation started.  It is used to keep the old event
   mask around, since that should be restored after the operation
   finishes.  */
static XWindowAttributes x_dnd_old_window_attrs;
1278 1279 1280

/* Whether or not `x_dnd_cleaup_drag_and_drop' should actually clean
   up the drag and drop operation.  */
static bool x_dnd_unwind_flag;

1283 1284 1285 1286 1287 1288 1289
/* The frame for which `x-dnd-movement-function' should be called.  */
static struct frame *x_dnd_movement_frame;

/* The coordinates which the movement function should be called
   with.  */
static int x_dnd_movement_x, x_dnd_movement_y;

1290 1291 1292 1293 1294
#ifdef HAVE_XKB
/* The keyboard state during the drag-and-drop operation.  */
static unsigned int x_dnd_keyboard_state;

1295 1296
/* jmp_buf that gets us out of the IO error handler if an error occurs
   terminating DND as part of the display disconnect handler.  */
Po Lu's avatar
Po Lu committed
static sigjmp_buf x_dnd_disconnect_handler;

1299 1300 1301 1302
/* Whether or not the current invocation of handle_one_xevent
   happened inside the drag_and_drop event loop.  */
static bool x_dnd_inside_handle_one_xevent;

1303 1304 1305 1306
/* The recursive edit depth when the drag-and-drop operation was
   started.  */
static int x_dnd_recursion_depth;

1307 1308 1309 1310 1311
/* The cons cell containing the selection alias between the Motif drag
   selection and `XdndSelection'.  The car and cdr are only set when
   initiating Motif drag-and-drop for the first time.  */
static Lisp_Object x_dnd_selection_alias_cell;

Po Lu's avatar
Po Lu committed
1312 1313
/* Structure describing a single window that can be the target of
   drag-and-drop operations.  */
1314 1315
struct x_client_list_window
Po Lu's avatar
Po Lu committed
  /* The window itself.  */
  Window window;
Po Lu's avatar
Po Lu committed
1318 1319

  /* The display that window is on.  */
  Display *dpy;
Po Lu's avatar
Po Lu committed
1321 1322

  /* Its X and Y coordinates from the root window.  */
  int x, y;
Po Lu's avatar
Po Lu committed
1324 1325

  /* The width and height of the window.  */
  int width, height;
Po Lu's avatar
Po Lu committed
1327 1328

  /* Whether or not the window is mapped.  */
  bool mapped_p;
Po Lu's avatar
Po Lu committed

1331 1332 1333
  /* A bitmask describing events Emacs was listening for from the
     window before some extra events were added in
     `x_dnd_compute_toplevels'.  */
  long previous_event_mask;
Po Lu's avatar
Po Lu committed
1335 1336

  /* The window manager state of the window.  */