[Uim] surrounding text

[YAMAMOTO Kengo / YamaKen]

At Tue, 10 Oct 2006 03:37:20 +0900,
ek.kato at gmail.com wrote:
> 
> Here is the details and problems.

> 2) For text acquisition in UTextArea_Selection and
> UTextArea_Clipboard, I made it fails upon UTextOrigin_Cursor origin
> since its meaning is unclear for me.  For the text extent, it support
> non-negative numbers and UTextExtent_Full.  Since the meaning of
> UTextExtent_Line in this case is unclear for me, I just assume it as
> UTextExtent_Full.

As written as follows along with enum UTextArea, the cursor of
UTextArea_Clipboard must always be positioned at end of the text
virtually.

/* Cursor of clipboard text is always positioned at end. */
enum UTextArea {
...
};

> 3) For text deletion, it support UTextArea_Primary and
> UTextArea_Selection text_id. And doesn't support UTextArea_Clipboard
> since it is meaningless.

Okay.

> 3') For text extent of deletion in UTextArea_Primary, it only support
> UTextOrigin_Cursor because of the restriction of
> gtk_im_context_delete_surrounding(), and it is needed to explicitly
> assign the length of former text and latter text.

Temporarily OK.

> 2') In GTK+'s clipboard on X11, a text acquired with
> GDK_SELECTION_PRIMARY with UTextArea_Selection doesn't mean it is the
> text on the target application.  I think this may cause some problems.
>  Possibly some other way to get a selected text on a widget may exist,
> but I'm not sure.

> 3'') For deletion in UTextArea_Selection, I just set the function
> delete_selection_text() empty and return success since I'm not sure
> how to delete selection text in GTK+, and I think it will be replaced
> newly committed text in the scenario #3.

Hmm... is it impossible to trick GTK+ to find the widget which
is associated with the input context? GtkEditable has the
features for our need.


> On 10/7/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > Please review the patch attached to. Though I said you about an
> > unified interface for these text acquisitions, I separated
> > string input as an independent interface to simplify internal
> > implementations after some considerations. This API is supposed
> > to work as follows.
> >
> > scenario #1: acquiring surrounding text
> >   1) Having a text "predecingIfollowing" on the textarea ("I" denotes cursor)
> >   2) (im-acquire-text c 'primary 'cursor 12 12)
> >   3) uc->acquire_text_cb(uc, UTextArea_Primary, UTextOrigin_Cursor, 12, 12)
> >   4) Returns result of (ustr-new '("preceding") '("following"))
> >   5) Split 3) into characters if needed
> >
> > scenario #2: acquiring full text for Japanese morphological analysis
> >   1) (im-acquire-text c 'primary 'end 'full 0)
> >   2) uc->acquire_text_cb(uc, UTextArea_Primary, UTextOrigin_End,
> >                          UTextExtent_Full, 0)
> >   3) Returns result of (ustr-new '("full text of the primary textarea") '())
> >   4) Analyze ustr-former-seq of 3) to select dictionary, or tune
> >      internal conversion parameters (assuming uim-anthy or uim-prime)
> >
> > scenario #3: reconversion of selection text by uim-anthy
> >   1) Select a text region by mouse
> >   2) Input a key that matches against anthy-reconversion-key?
> >   3) (im-acquire-text ac 'selection 'end 'full 0)
> >   4) uc->acquire_text_cb(uc, UTextArea_Selection, UTextOrigin_End,
> >                          UTextExtent_Full, 0)
> >   5) The bridge returns selected text
> >   6) Returns result of (ustr-new '("text to be reconverted") '())
> >   7) (im-delete-text ac 'selection 'end 'full 0)
> >   8) uc->delete_text_cb(uc, UTextArea_Selection, UTextOrigin_End,
> >                         UTextExtent_Full, 0)
> >   9) The bridge deletes selected text
> >   10) Reconvert ustr-former-seq of 9)
> >
> > scenario #4: insert a text read from clipboard into preedit by uim-skk
> >   1) Convert a text and fall into word-registering mode
> >   2) Look up the kanji-word of 1) by a dictionary application
> >   3) Select the kanji-word 2)
> >   4) Re-select the textarea 1)
> >   5) Input a key that matches against skk-yank-from-clipboard?
> >   6) (im-acquire-text sc 'clipboard 'end 'full 0)
> >   7) uc->acquire_text_cb(uc, UTextArea_Clipboard, UTextOrigin_End,
> >                          UTextExtent_Full, 0)
> >   8) The bridge acquire the text of clipboard copied at 3)
> >   9) Returns result of (ustr-new '("the kanji-word") '())
> >   10) Yank the kanji-word into the preedit to be registered
> >
> > scenario #5: insert a pasted text into preedit by uim-skk
> >   1) Convert a text and fall into word-registering mode
> >   2) Look up the kanji-word of 1) by a dictionary application
> >   3) Select the kanji-word 2)
> >   4) Re-select the textarea 1)
> >   5) Paste the kanji-word by mouse
> >   6) The bridge filters the paste event
> >   7) uim_input_string(uc, "the kanji-word")
> >   8) (input-string-handler id "the kanji-word")
> >   9) Yank the kanji-word into the preedit to be registered

> > enum UTextExtent
> > bridge_text_acquisition_capability(void)
> > {
> >   /* low-active OR */
> >   return ~(~UTextExtent_Full | ~UTextExtent_Line | ~UTextExtent_Paragraph);
> > }
> >
> >
> > /* low-active input AND */
> > if (~bridge_text_acquisition_capability() & ~UTextExtent_CharFrags) {
> >   ...
> > }
> 
> I think these text acquisition capability value may change depending
> on whether requested area is primary, clipboard, selection.

It is written as just an instance. Don't mind its accurate usage
for now.

------------------------------------------------
YAMAMOTO Kengo / YamaKen  yamaken at bp.iij4u.or.jp
FAMILY   Given / Nick