[Uim] surrounding text

[Etsushi Kato]

On 10/10/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 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.

I see.  But how about selection?  Is it also applicable to it?  And
how do I treat UTextExtent_Line in selection/clipboard?


> > 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.

Yes.  Our GTK+ bridge knows its widget of the context.  I'll
investigate more later about this.  But we can't assume all the widget
of the input context support GtkEditable, I think.

> > 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.

OK.

Cheers,
-- 
Etsushi Kato
ek.kato at gmail.com