sundar@WHEATIES.AI.MIT.EDU (Sundar Narasimhan) (01/19/89)
Hi: I have a ttyWidget that expects to draw the cursor when it receives an EnterNotify event (sort of like emacs). It also expects to redraw the entire text in it when it receives an Expose event. This works fine normally, but when the user uses a chorded window-manager key (like say Meta-LEFT) to circulate the window up from a behind a whole stack of windows, the widget seems to get the Expose all right, but not the EnterNotify event. Needless to say, this causes the text to be displayed correctly, but not the cursor. This is somewhat annoying. Can someone explain to me what the right behaviour (at the widget level) should be? (Should Expose be really treated as Expose&EnterNotify)? Secondly, in R3, what is the right way to deal with the mouse cursor when you are managing text in a widget by yourself? The reason I ask this is that in my ttyWidget since I have to manage the block cursor myself, I have to paint the characters in inversevideo myself (I am using XDrawImageString for this). However, when I do this I notice that sometimes the mouse cursor causes silly turd like droppings on the screen if it happens to be near where my text cursor is. Is one supposed to hide the mouse cursor before calling XDrawImageString? How does one prevent the mouse cursor from interacting with XDrawImageString, or is there something else I am doing wrong? -Sundar Why, oh why do we have to worry about cursors ?! (Every program is now going to have to maintain state for this, what fun!)
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (01/19/89)
> However, when I do this I notice that > sometimes the mouse cursor causes silly turd like droppings on the > screen if it happens to be near where my text cursor is. This sounds like a bug in your server. If you can show us how to reproduce it (esp. a nice small test case we could run here), xbugs would love to hear about it. > Why, oh why do we have to worry about cursors ?! Don't worry. You shouldn't have to. Jim
kit@ATHENA.MIT.EDU (Chris D. Peterson) (01/20/89)
> Hi: I have a ttyWidget that expects to draw the cursor when it > receives an EnterNotify event (sort of like emacs). Use FocusIn event, instead. Chris D. Peterson MIT X Consortium / Project Athena Net: kit@athena.mit.edu Phone: (617) 253 - 1326 USMail: MIT - Room E40-321 77 Massachusetts Ave. Cambridge, MA 02139
sundar@WHEATIES.AI.MIT.EDU (Sundar Narasimhan) (01/20/89)
Date: Thu, 19 Jan 89 13:16:43 EST From: Chris D. Peterson <kit@athena.mit.edu> > Hi: I have a ttyWidget that expects to draw the cursor when it > receives an EnterNotify event (sort of like emacs). Use FocusIn event, instead. Chris D. Peterson MIT X Consortium / Project Athena Net: kit@athena.mit.edu Phone: (617) 253 - 1326 USMail: MIT - Room E40-321 77 Massachusetts Ave. Cambridge, MA 02139 This doesn't work. I should have mentioned that I have something like static char default_translations[] = "<Key>: tty_callback() \n\ <EnterWindow>: tty_highlight() \n\ <LeaveWindow>: tty_unhighlight()"; for doing this.. If I change the translations to be <FocusIn> and <FocusOut>, the two routines never seem to get invoked.. -Sundar
Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (01/21/89)
> > Hi: I have a ttyWidget that expects to draw the cursor when it > > receives an EnterNotify event (sort of like emacs). > > Use FocusIn event, instead. > > This doesn't work. I should have mentioned that I have something like > > static char default_translations[] = > "<Key>: tty_callback() \n\ > <EnterWindow>: tty_highlight() \n\ > <LeaveWindow>: tty_unhighlight()"; > > for doing this.. If I change the translations to be <FocusIn> and > <FocusOut>, the two routines never seem to get invoked.. Undoubtedly, you running with focus=PointerRoot, the default situation unless you're using a window manager (or some other bold client) that enforces click-to-type. In this case, when the pointer moves into window W, then W becomes the effective keyboard focus, but W will never get FocusIn/Out events. At least that's my observation of server behavior. Under a Talmudic interpretation of the Protocol, this is legit since the fact that focus=PointerRoot has not changed. In practice, however, this amounts to a defect in the protocol, because it severely constrains the usefulness of FocusIn/Out.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/21/89)
In practice, however, this amounts to a
defect in the protocol, because it severely constrains the usefulness of
FocusIn/Out.
True. Note that Enter/Leave events contain a focus flag, which was supposed
to carry the same information. And it does, except for unpleasant interactions
with pointer grabs that we didn't realize early enough on. It is thought that
a reasonable (hopefully upward compatible) design change would be to always
send FocusIn/Out events when windows get/lose the focus (e.g. with a new
detail "Pointer"). I suspect this is on Hania's list at her X Conference
talk ...