[WASTE-list] WESetEventTarget

[Marco Piovanelli]

On Fri, 9 Dec 2005 20:58:10 -0500,
Alfred Van Hoek (vanhoek at mac.com) wrote:


>WEKey is deprecated and we require to use WESetEventTarget to take 

>advantage of Unicode.  The documentation says: "instead of feeding raw 

>keyboard events to WEKey, you should install text input event 

>handlers".

>

>Does it mean we should provide something like:

>

>#if (WASTE_VERSION >= 0x03000000)


Yes, assuming you're writing code meant to work with both
version 2.1 and 3.0 of WASTE.


>pascal OSStatus

>	My_DispatcherHandler

>		(EventHandlerCallRef inCaller,

>		EventRef inEvent,

>		void* inRefcon)

>	{

>		// and Waste extracts the rawkeyEvent, we don't need to do here 

>anything

>		// it appears to work for a U.S. encoding, but not for Arabic-QWERTY 

>(it types

>		// but it is all squares


This is a font problem, not a text input problem: Arabic
characters are inserted correctly, but the current font
doesn't have the required glyphs.  Try enabling ATSUI
transient font matching:

  WEFeatureFlag(weFTransientFontMatching, weBitSet, myWE);

This should take care of this problem, but it may also
degrade performance.  So a better solution would be to
automatically select an Arabic font when the user switches
to an Arabic keyboard -- in fact WASTE used to do this up
to version 2.1: it was called "font/keyboard synchronization".
I'll try to come up with a similar feature for WASTE 3.0,
but in the brave new Unicode world, there's no longer a
concept of font script or keyboard script.


>And it also appears that under these conditions (in above context, and 

>to be expected) that there isn't much control to filter text.


There is actually a new (so far undocumented) callback that
lets you filter text received by WASTE through text input
events.  You can install this callback by using WESetInfo()
with the weTextFilterProc selector, like this:

  static WETextFilterUPP myTextFilter = NewWETextFilterUPP(MyTextFilter);

  err = WESetInfo(weTextFilterProc, &myTextFilter, myWE);

The filter callback should be declared like this:

  Boolean   MyTextFilter
	     (
            ComponentInstance	 inTextInputComponent,
		          Handle				         inFilterableText,
		          UInt32				         inModifiers,
		          UInt32				         inKeyCode,
		          WEReference			     inWE
      );

Where:

inTextInputComponent is the text input component that's
sending the text to the application, or 0 if the text does
not come from a text input component (e.g., if it comes
from a regular keyboard).

inFilterableText is the array of UniChar's as received by
WASTE.  Used GetHandleSize() to calculate the actual number
of characters.  In most cases, the character count will be 1,
but text input methods and certain Unicode keyboards (uchr)
can send multiple characters at once.  You can manipulate
this buffer in any way you see fit, including shrinking or
extending it.  Setting the handle size to 0 is tantamount
to rejecting the input.

inModifiers and inKeyCode are extracted from the original
key down event, if any.  They are not meaningful (and are
set to 0) if the text comes from an input method.

The function result should be true if the hook has modified
the text in any way, false otherwise.

WASTE will call the filter hook whenever user-entered text
is about to be inserted into a document, regardless of whether
it comes from a keyboard or an input method, and regardless
of the particular event kind received by WASTE
(kEventTextInputUnicodeForKeyEvent, kEventTextInputUpdateActiveInputArea,
etc.)

This hook will *not* be invoked for raw (unconfirmed) text
that may be entered into the TSM input area while an inline
input session is in progress.  Remember, though, that you
can force an inline input session to be closed at any time
by calling WEStopInlineSession().


>We liked WEKey, and would liked to have seen us to send the 

>textEncoding, the UniChar etc. Wouldn't this be better then letting 

>Waste dispatching the event? Is Waste dispatching it?


I'm sorry, but WEKey, or a revision thereof, just wouldn't cut it.
Handling text input properly on Mac OS X is a pretty complicated
matter, and involves installing a number of Carbon event handlers,
not just kEventTextInputUnicodeForKeyEvent.

Also, text input events aren't used just for keyboard input,
but also for things like interacting with the Character Palette,
and dictionary lookup (try pressing command-control-D when the
cursor is over a word in a WASTE document to see what I mean).

It's just easier to let WASTE install its own Carbon event handlers
(there are currently eight of them being installed just for text
input, but this number will likely grow).


>Any clues how we should address the problem?


Hopefully the filter hook I described above is enough to address
your needs.


                                        -- marco

-- 
It's not the data universe only, it's human conversation.
They want to turn it into a one-way flow that they have entirely
monetized. I look at the collective human mind as a kind of
ecosystem. They want to clear cut it. They want to go into the
rainforest of human thought and mow the thing down.