home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.windows.x.motif
- 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
- From: tommc@hpcvusc.cv.hp.com (Tom McFarland)
- Subject: Re: XmText cursor sticking around (1.2.1)
- Message-ID: <1993Jan28.184505.18053@hpcvusn.cv.hp.com>
- Sender: nobody@hpcvusn.cv.hp.com (Nobody - UID must be 99999)
- Nntp-Posting-Host: hpcvusc.cv.hp.com
- Reply-To: tommc@cv.hp.com
- Organization: Hewlett Packard UTD-Corvallis
- References: <1993Jan7.001318.27715@CSD-NewsHost.Stanford.EDU>
- Date: Thu, 28 Jan 1993 18:45:05 GMT
- Lines: 38
-
- In article <1993Jan7.001318.27715@CSD-NewsHost.Stanford.EDU>, rfrench@Xenon.Stanford.EDU (Robert S. French) writes:
- |> I'm having a lot of trouble with the Motif 1.2.1 XmText widget. If I
- |> have multiple XmText widgets in some kind of form, and hit "TAB" when
- |> the cursor is "on" in one of the widgets, the cursor stays there
- |> (unblinking). When I hit "TAB" when the cursor is "off", it stays
- |> gone. This allows you to have non-blinking cursors in all of your
- |> text widgets simultaneously, which is ugly at best. I'm pretty sure
- |> it's not just my application since the demos do it too. Any hints on
- |> how to fix this?
-
- This is the new style guide compliant behavior dictated by OSF for 1.2.
- If a text widget has the focus, it has a solid (non-stippled) I-Beam cursor.
- If a text widget does not have the focus, it has a stippled I-Beam cursor,
- except if the text widget owns the Motif destination selection; if it owns
- the destination selection, it displays a solid non-blinking I-Beam cursor.
- If you are getting multiple non-stippled I-Beam cursors (other than one
- in the text widget with focus and one in a text widget that owns the
- destination), then there is a bug in the text widget.
-
- A bit of history...
-
- In pre-1.2, destination ownership was indicated by displaying the "carat
- cursor". Also, in pre-1.2 location of the destination could be disjoint
- from the insertion point; as of 1.2, destination location and insertion point
- are always at the same position. OSF recieved lots of questions along the
- lines "What the heck is this 'hat' character doing in the baseline of my
- text widget?". So, they dropped the different cursor for the destination.
- However, they felt it was still important to see where the result of quick-cut
- and quick-copy operations would be sent, so they created the new semantic for
- showing location of the destination selection.
-
- |> Rob
- |>
-
- Tom McFarland
- Hewlett-Packard, Co.
- R&D Motif team
- <tommc@cv.hp.com>
-