Mercurial > hg > xemacs-beta

comparison src/event-Xt.c @ 448:3078fd1074e8 r21-2-39

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Import from CVS: tag r21-2-39
author cvs
date Mon, 13 Aug 2007 11:38:25 +0200
parents 1ccc32a20af4
children 98528da0b7fc
comparison
equal deleted inserted replaced
447:4fc5f13f3bd3 448:3078fd1074e8
1761 } 1761 }
1762 #endif 1762 #endif
1763 } 1763 }
1764 } 1764 }
1765 1765
1766 /* #### I'm struggling to understand how the X event loop really works.
1767 Here is the problem:
1768
1769 When widgets get mapped / changed etc the actual display updates
1770 are done asynchronously via X events being processed - this
1771 normally happens when XtAppProcessEvent() gets called. However, if
1772 we are executing lisp code or even doing redisplay we won't
1773 necessarily process X events for a very long time. This has the
1774 effect of widgets only getting updated when XEmacs only goes into
1775 idle, or some other event causes processing of the X event queue.
1776
1777 XtAppProcessEvent can get called from the following places:
1778
1779 emacs_Xt_next_event () - this is normal event processing, almost
1780 any non-X event will take precedence and this means that we
1781 cannot rely on it to do the right thing at the right time for
1782 widget display.
1783
1784 drain_X_queue () - this happens when SIGIO gets tripped,
1785 processing the event queue allows C-g to be checked for. It gets
1786 called from emacs_Xt_event_pending_p ().
1787
1788 In order to solve this I have tried introducing a list primitive -
1789 dispatch-non-command-events - which forces processing of X events
1790 related to display. Unfortunately this has a number of problems,
1791 one is that it is possible for event_stream_event_pending_p to
1792 block for ever if there isn't actually an event. I guess this can
1793 happen if we drop the synthetic event for reason. It also relies on
1794 SIGIO processing which makes things rather fragile.
1795
1796 People have seen behaviour whereby XEmacs blocks until you move the
1797 mouse. This seems to indicate that dispatch-non-command-events is
1798 blocking. It may be that in a SIGIO world forcing SIGIO processing
1799 does the wrong thing.
1800 */
1766 static void 1801 static void
1767 emacs_Xt_force_event_pending (struct frame* f) 1802 emacs_Xt_force_event_pending (struct frame* f)
1768 { 1803 {
1769 XEvent event; 1804 XEvent event;
1770 1805
1776 event.xclient.window = 0; 1811 event.xclient.window = 0;
1777 1812
1778 /* Send the drop message */ 1813 /* Send the drop message */
1779 XSendEvent(dpy, XtWindow (FRAME_X_SHELL_WIDGET (f)), 1814 XSendEvent(dpy, XtWindow (FRAME_X_SHELL_WIDGET (f)),
1780 True, NoEventMask, &event); 1815 True, NoEventMask, &event);
1781 /* Force event pending to check the X queue. */ 1816 /* We rely on SIGIO and friends to realise we have generated an
1782 quit_check_signal_tick_count++; 1817 event. */
1783 } 1818 }
1784 1819
1785 static void 1820 static void
1786 emacs_Xt_handle_magic_event (Lisp_Event *emacs_event) 1821 emacs_Xt_handle_magic_event (Lisp_Event *emacs_event)
1787 { 1822 {
2947 */ 2982 */
2948 2983
2949 /* quit_check_signal_tick_count is volatile so try to avoid race conditions 2984 /* quit_check_signal_tick_count is volatile so try to avoid race conditions
2950 by using a temporary variable */ 2985 by using a temporary variable */
2951 tick_count_val = quit_check_signal_tick_count; 2986 tick_count_val = quit_check_signal_tick_count;
2952 if (last_quit_check_signal_tick_count != tick_count_val) 2987 if (last_quit_check_signal_tick_count != tick_count_val
2988 #if !defined (SIGIO) || defined (CYGWIN)
2989 || (XtIMXEvent & XtAppPending (Xt_app_con))
2990 #endif
2991 )
2953 { 2992 {
2954 last_quit_check_signal_tick_count = tick_count_val; 2993 last_quit_check_signal_tick_count = tick_count_val;
2955 2994
2956 /* We need to drain the entire queue now -- if we only 2995 /* We need to drain the entire queue now -- if we only
2957 drain part of it, we may later on end up with events 2996 drain part of it, we may later on end up with events