Jean-Marc Lasgouttes wrote:
>>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
>>> void fl_get_composed_string(int * ptr_kbuflen, char const *
>>> ptr_keybuf) { if (!ptr_kbuflen) return; *ptr_kbuflen = kbuflen;
>>> ptr_keybuf = keybuf; }
>
> Angus> It may be that this function should be written:
>
> Angus> void fl_get_composed_string(int * ptr_kbuflen, char const **
> Angus> ptr_keybuf) { if (!ptr_kbuflen) return; *ptr_kbuflen =
> kbuflen; Angus> *ptr_keybuf = &keybuf; }
>
> Angus> I get confused by pointers sometimes. Untested of course ;-)
>
> BTW angus, would your changes to xforms preserve xforms behaviour
> for other applications? We have to be careful about source-level
> compatibility for changes that we propose.
>
> JMarc
Not if they have their own widgets for input, no. If they have their
own widgets, then they will have special code for things like Escape
(char = 27 as opposed to keysym = XK_Escape). Ditto, their modifier
key stuff will use different mechanisms to detect whether a Alt or
Ctrl were pressed with the key. My proposal (pass the keysym rather
than keybuf, char by char) unifies these behaviours.
Of course, if they, like us, just threw away xforms' handling of
keyboard events and started anew from the raw XEvents, then they will
be able to continue doing so.
I'm of the opinion that fl_handle_form is passed keybuf char by char
rather than passing a single keysym per XEvent in an attempt to
enable CJK type multi-byte input. However, I think that in this case
it would be cleaner to tell the widget that an event has occurred and
that it should pick up the keybuf (using some accessor function) if
it wants it. 'Normal' users would then not be penalised by obfuscated
code.
--
Angus
