![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to README.rtf CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [NeXTSTEP 3.3 examples] / Examples / AppKit / UnderPressure|
Return to README.rtf CVS log | Up to [NeXTSTEP 3.3 examples] / Examples / AppKit / UnderPressure |
1.1 root 1: {\rtf0\ansi{\fonttbl\f0\fswiss Helvetica;\f1\fmodern Ohlfs;}
2: \paperw9840
3: \paperh14000
4: \margl120
5: \margr120
6: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\f0\b0\i0\ulnone\fs24\fc0\cf0 \
7: \
8:
9: \b UnderPressure\
10: by Peter Graffagnino\
11: \
12: UnderPressure
13: \b0 is a simple application demonstrating how to take advantage of the pressure sensitive features of graphics tablets under NeXTSTEP 3.0. It is basically a simple paint program that draws variable-width brush strokes. The application consists of only two custom classes
14: \b PressureView
15: \b0 and
16: \b Brush
17: \b0 .
18: \b PressureView
19: \b0 serves two illustrative purposes. Most importantly, it shows how to set up a view to inform the event system that it is interested in pressure events. Secondarily, it shows how to implement a View with a backing store using
20: \b NXImage
21: \b0 . The
22: \b Brush
23: \b0 class implements a simple moveto/lineto brush protocol, and demonstrates a reasonably efficient way to draw a variable width line using linecaps and trapezoidal fillets.\
24: \
25:
26: \b Areas of Interest Demonstrated in UnderPressure\
27:
28: \b0 \
29: � maintaing special event trackingrects for pressure and event coalescing (PressureView)\
30: � a simple paint-brush model (Brush)\
31: � fast filled circles using linecaps (Brush)\
32: � using an NXImage to provide a backing store for a View (PressureView)\
33: � using phantom outlets to set default control values at nib loading (Brush)\
34: � handling pen proximity events as flags changed (PressureView)\
35: \
36: \
37: \
38:
39: \b Technical Details of Pressure Support in 3.0.\
40: \
41:
42: \b0 NeXTSTEP 3.0 supports the pressure-sensitive features of WACOM tablets. The pressure-pen emits a continuous range of values from its pressure-sensitive tip. In order for the pen to be used as a generic pointing device (i.e. a mouse substitute), mouse-up and mouse-down events need to be synthesized by the low-level tablet driver. This is done using a pair of thresholds to implement a "debounced" binary switch -- a fairly large pressure threshold is used to determine when to switch from mouse-up to mouse-down, and a fairly light pressure threshold is used to determine when to switch from mouse-down to mouse-up. This behavior enables the pressure pen to be used with any application -- emulating a mouse as closely as possible. However, for applications that want to take advantage of pressure, this is clearly not the right model. For example, if a paint program goes into its modal painting loop on mouseDown:, it would loose all of the valuable pressure data which was lighter than the mouseDown threshold! To solve this problem, applications that are pressure-aware need to inform the event system that they are interested in all pressure events (not just mouse emulation). In this mode the system will treat any non-zero pressure as a mouse-down, and zero pressure as mouse-up. Since this is most useful on a View basis, this mode is set up using the array form of WindowServer's
43: \b settrackingrect
44: \b0 operator, which is new in 3.0 (see
45: \b pressurerect.psw
46: \b0 ). As
47: \b PressureView
48: \b0 demonstrates, it's fairly easy to maintain the appropriate tracking rect, by overriding the
49: \b resetCursorRects
50: \b0 method in View. Notice that the extra sensitivity in
51: \b UnderPressure
52: \b0 only takes place in the
53: \b PressureView
54: \b0 , not on the other controls in the window. -- a light stroke on the canvas will mark a thin line, whereas a similar stroke on the scrollbar will have no effect. This is because outside the tracking rectangle set up by
55: \b PressureView
56: \b0 , normal mouse emulation thresholds are used to determine mouseDown.\
57: \
58: Another feature added to the event subsystem for 3.0 is the ability to disable event coalescing in the system. Normally in NeXTSTEP events are aggressively coalesced making the feedback loop as tight as possible. Sometimes, particularly with pen input devices, this is not what an application might want. For example, an application digitizing a pen-stroke for handwriting recognition, might want all of the data from the input device. Also, a painting program might in fact want to lag somewhat, in order to more faithfully render the user's gesture. In 3.0, event-coalescing can also be controlled on a per-trackingrect basis.
59: \b PressureView
60: \b0 also demonstrates this.\
61: \
62: Event coalescing occurs at two different levels in NeXTSTEP. All events flow from the input device, to the kernel, from the kernel to the WindowServer, and from the WindowServer to dpsclient (in your application). Events can get coaleseced in the kernel or in dpsclient. When a tracking rect is setup to disable event coalescing, the kernel will avoid coalescing the event, and stamp in with the
63: \b NX_NONCOALSCEDFLAG
64: \b0 in the event flag field. As this event percolates up through the system, other layers of software will avoid coalecing the event. (Note: dpsclient event coalecing can be controlled separately with the
65: \b DPSSetTracking
66: \b0 () function, however
67: \b NX_NONCOALSCEDFLAG
68: \b0 events are never coalesced regardless of the state of the
69: \b DPSSetTracking
70: \b0 flag.\
71: \
72: \
73: \
74: \
75: \
76: \
77: \
78: \
79:
80: }
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.