[Uim] surrounding text

[YAMAMOTO Kengo / YamaKen]

At Tue, 10 Oct 2006 14:31:01 +0900,
ek.kato at gmail.com wrote:
> 
> 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?

It is positioned at end or beginning of the text in accordance
with the dragged direction. acquire_cb should reflect it. But if
it is not detectable, end of the text is appropriate fallback
for the cursor position.

> And how do I treat UTextExtent_Line in selection/clipboard?

Oops. I forgot to reply to it.

Suppose the clipboard is having this string.

  "first line.\nsecond LINE.\nthird LiNe."

In this case,
  (UTextOrigin_End, UTextExtent_Line) returns "third LiNe."
  (UTextOrigin_Beginning, UTextExtent_Line) returns "first line."

And one another.

  "\nfirst line.\nsecond LINE.\nthird LiNe.\n"

  (UTextOrigin_End, UTextExtent_Line) returns ""
  (UTextOrigin_Beginning, UTextExtent_Line) returns ""

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

I see. I'll relax the specification once your investigation (and
implementation) has been finished.

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