home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / windows / x / motif / 8904 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.5 KB  |  52 lines

  1. Newsgroups: comp.windows.x.motif
  2. Path: sparky!uunet!europa.eng.gtefsd.com!emory!sol.ctr.columbia.edu!usc!sdd.hp.com!hp-cv!hp-pcd!hpcvusn!hpcvusc.cv.hp.com!tommc
  3. From: tommc@hpcvusc.cv.hp.com (Tom McFarland)
  4. Subject: Re: XmText cursor sticking around (1.2.1)
  5. Message-ID: <1993Jan28.184505.18053@hpcvusn.cv.hp.com>
  6. Sender: nobody@hpcvusn.cv.hp.com (Nobody - UID must be 99999)
  7. Nntp-Posting-Host: hpcvusc.cv.hp.com
  8. Reply-To: tommc@cv.hp.com
  9. Organization: Hewlett Packard UTD-Corvallis
  10. References:  <1993Jan7.001318.27715@CSD-NewsHost.Stanford.EDU>
  11. Date: Thu, 28 Jan 1993 18:45:05 GMT
  12. Lines: 38
  13.  
  14. In article <1993Jan7.001318.27715@CSD-NewsHost.Stanford.EDU>, rfrench@Xenon.Stanford.EDU (Robert S. French) writes:
  15. |> I'm having a lot of trouble with the Motif 1.2.1 XmText widget.  If I
  16. |> have multiple XmText widgets in some kind of form, and hit "TAB" when
  17. |> the cursor is "on" in one of the widgets, the cursor stays there
  18. |> (unblinking).  When I hit "TAB" when the cursor is "off", it stays
  19. |> gone.  This allows you to have non-blinking cursors in all of your
  20. |> text widgets simultaneously, which is ugly at best.  I'm pretty sure
  21. |> it's not just my application since the demos do it too.  Any hints on
  22. |> how to fix this?
  23.  
  24. This is the new style guide compliant behavior dictated by OSF for 1.2.
  25. If a text widget has the focus, it has a solid (non-stippled) I-Beam cursor.
  26. If a text widget does not have the focus, it has a stippled I-Beam cursor,
  27. except if the text widget owns the Motif destination selection; if it owns
  28. the destination selection, it displays a solid non-blinking I-Beam cursor.
  29. If you are getting multiple non-stippled I-Beam cursors (other than one
  30. in the text widget with focus and one in a text widget that owns the
  31. destination), then there is a bug in the text widget.
  32.  
  33. A bit of history...
  34.  
  35. In pre-1.2, destination ownership was indicated by displaying the "carat
  36. cursor".  Also, in pre-1.2 location of the destination could be disjoint
  37. from the insertion point; as of 1.2, destination location and insertion point
  38. are always at the same position.  OSF recieved lots of questions along the
  39. lines "What the heck is this 'hat' character doing in the baseline of my
  40. text widget?".  So, they dropped the different cursor for the destination.
  41. However, they felt it was still important to see where the result of quick-cut
  42. and quick-copy operations would be sent, so they created the new semantic for
  43. showing location of the destination selection.
  44.  
  45. |>             Rob
  46. |> 
  47.  
  48. Tom McFarland
  49. Hewlett-Packard, Co.
  50. R&D Motif team
  51. <tommc@cv.hp.com>
  52.