* More bug chasing:						-*- coding: utf-8 -*-

how-to repeat:

suse:     rug in scim scim-uim scim-tables-ja kinput2
ubuntu:   apt-get install scim scim-uim scim-tables-ja scim-gtk2-immodule \
	  kinput2-canna uim-xim uim-gtk2.0 uim-xim anthy

xim+scim:

Set GTK_IM_MODULE(S?) to override gtk's default input method (i.e. the
last entry in /etc/gtk-2.0/gtk.immodules). Set OOO_FORCE_DESKTOP=none
to compare with the generic X vclplug which ignores gtk's default
anyway.

suse:
XIM_PROGRAM=scim LANG=ja_JP.UTF-8 GTK_IM_MODULES=xim XMODIFIERS=@uim=anthy scim -d
XIM_PROGRAM=scim LANG=ja_JP.UTF-8 GTK_IM_MODULES=xim XMODIFIERS=@uim=anthy ./soffice.bin -writer

ubuntu:
XIM_PROGRAM=scim LANG=ja_JP.UTF-8 GTK_IM_MODULE=xim XMODIFIERS=@im=SCIM scim -d
XIM_PROGRAM=scim LANG=ja_JP.UTF-8 GTK_IM_MODULE=xim XMODIFIERS=@im=SCIM ./soffice.bin -writer

xim+kinput2:

suse:
LANG=ja_JP.UTF-8 GTK_IM_MODULES=xim XMODIFIERS=@im=kinput2 ./soffice.bin -writer

ubuntu:
XIM_PROGRAM=canna LANG=ja_JP.UTF-8 GTK_IM_MODULE=xim XMODIFIERS=@im=kinput2 kinput2 -canna
XIM_PROGRAM=canna LANG=ja_JP.UTF-8 GTK_IM_MODULE=xim XMODIFIERS=@im=kinput2 ./soffice.bin -writer

xim+uim:

uim-xim&
LANG=ja_JP.UTF-8 GTK_IM_MODULE=xim XMODIFIERS=@im=uim ./soffice.bin -writer

gtk+scim:

LANG=ja_JP.UTF-8 scim -d
LANG=ja_JP.UTF-8 GTK_IM_MODULE=scrim ./soffice.bin -writer

gtk+uim:

LANG=ja_JP.UTF-8 GTK_IM_MODULE=uim ./soffice.bin -writer


---------------- switching focus bugs ------------------------

+ Switch from OO.o <-> OO.o
    + emits EndExtTextInput call [ problematic ]
        + http://bugzilla.suse.de/show_bug.cgi?id=49105
    + OO.o synthesises this call (somehow)
	+ winproc.cxx [ synthesises ExtEndTextInput on mouse click ]
	  + [ this is the cause of the trouble ]
    + Works on the understanding:
	+ we have to end this pre-edit: now !
	+ unfortunately the IM API is not like that [!]
	    + _it_ controls when the pre-edit ends ...
    + ARGH [!]

** Problem **
   + gtk_im_context_reset - non-functional except with 'xim'
   + scim: broken.
	+ does do something [ but not end pre-edit ;-]
	+ belt & braces - synthesis hard end to input ...

** Problem **
   + opening menus eg. - Alt-F

---------------- ending of IM predit bugs ------------------------

RH bugs:
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134022

Novell person:
	http://bugzilla.ximian.com/show_bug.cgi?id=68885

    + The IM outputs events like this:

    [ start pre-edit ]
:signalImPreeditChanged ''
:signalImPreeditChanged 'f'
:signalImPreeditChanged 'f'
:signalImPreeditChanged 'f'
:signalImPreeditChanged 'fo'
:signalImPreeditChanged 'fo'
:signalImPreeditChanged 'fo'
:signalImPreeditChanged 'foo'
:signalImPreeditChanged 'foo'
UpdateIMSpotLocation: SetCursorLocation
    [ end pre-edit]
:signalImPreeditChanged ''

	+ ie. we never get a 'pre-edit end' signal,
	    + however - we do get an 'empty'
	      signalImPreeditChanged
 

    * serious bug:
	+ start pre-edit; type some chars
	    + end pre-edit
	+ move somewhere else
	+ re-start pre-edit
	    + no text / pre-edit shows up [!?] 

    Dan's patch:
	+ http://www.openoffice.org/nonav/issues/showattachment.cgi/18809/i18n-gtk-im-keyrelease-fix.diff
	+ backspace to line begginning ...

    * Moving a pre-edit around:
	+ C-space 'nippon' C-space
	  <move elsewhere>
	+ C-space
	+ should insert the pre-edit into the text there.
	    * pre-edits should be over-written [selection?] when move/re-edit (?)

    * pre-edits should complete/insert only when selected 
	+ should stay underlined until space/enter in pre-edit mode (!?)

    + Check vs. non-GTK foo ...

http://www.openoffice.org/issues/show_bug.cgi?id=34880
Hm, as far as I can tell this breaks word wise editing, assuming you have
several words in preedit buffer.
Situation:
type several japanes words but don't commit the preedit buffer (common use). Now
with Ctrl + Cursor left/right you can travel wordwise in preedit.
But with the patch the buffer gets commited as soon as you hit Ctrl and is
pasted again when hitting cursor left or right.
I don't think we should commit this one.
Tested with iiimf 12.1 (fedora core 2 latest developer builds)

       + Or:
       http://bugzilla.suse.de/show_bug.cgi?id=48120

Some of Anthy keybind doesn't work correctly on OOo with gnome session.  
The installed Anthy is anthy-5714-1.2.  
OpenOffice is  
OpenOffice_org-1.1.3-16 
OpenOffice_org-gnome-1.1.3-16 
OpenOffice_org-ja-1.1.3-16 
OpenOffice_org-kde-1.1.3-16 
 
 
Anthy keybind is introduced at here. 
http://anthy.sourceforge.jp/cgi-bin/hikija/hiki.cgi?%A5%AD%A1%BC%A5%D0%A5%A4%A5%F3%A5%C9#l0

[Is this the corresponding translation?]
http://anthy.sourceforge.jp/cgi-bin/hikien/hiki.cgi?uim-anthy
 
e.g. Keybind "shift + ←" and "Ctrl + h" is defined with Anthy by default. 
However, OOo with gnome session, this keybind doesn't work fine. 
in contrast this keybind works fine with OOo on kde session.

* How to reproduce:

  
1, Start OOo with gnome session and create new document. 
2, Push "Shift+space", Japanese input mode activates. 
3, Input Japanese letters something, e.g. "aiueo"(Hiragana be displayed). 
   then push space key. Japanese letters changes to candidate kanji. 
4, At this stage, if push keybind "Shift + ←", it provides function that make 
   paragraphs short. 
   but this keybind function ignored and unwiehd strings committed. 
   (Strings looks committed just after push Shift key without "←",) 
5, At step4, in case push "Ctrl + h" also doesn't work. This Anthy  
   keybinded function ignored and strings be committed.   
   (Strings looks committed just after Ctrl key without "h",) 
 
  
With gnome-terminal, keybind above works fine.



* Chasing SuSE bug #46365

* Problem 1.4:
	+ winproc.xx (IpmlHandleExtTextInput):
		+ ImplHandleEndExtTextInput ...


	+ EndExtTextInput
	    + not doing it's job ?
	+ On non-IM keypress
	    + do a reset ?
	+ perhaps m_bWasPreedit problem (?)
	+ other events [ key move / delete etc. in-between bits ... ]


Method to reproduce problem 1.4:

GTK_IM_MODULE=xim XMODIFIERS=@im=SCIM oowriter

Shift+Space to switch on scim. Choose UIM-anthy input method.
Type 

    a a a RETURN RETURN
    a a a RETURN RETURN

You should now see:

あああ
あああ

Select all of this with the mouse. Press Delete. All text is deleted.
The input method is still switched on!
Type 

   a a a 

again. 

You cannot see any input.

Switch off input method with Shift+Space.

Type 

  a b c

Latin letters are inserted.

Switch on input method with Shift+Space. Now the 3 Japanese 'a' 
which were already typed before but didn't become visible are inserted.
The buffer now looks like:

abcあああ


So far:
	+ it looks like the IM setup / teardown / associate & de-associate
	  are not happening correctly - ie. on focus in / out / realise /
	  unrealise or whatever.
	    GtkEntry::realise
		+ gtk_im_context_set_client_window (entry->im_context, entry->text_area);
	    GtkEntry::unrealise
		+ gtk_im_context_set_client_window (entry->im_context, NULL);
	+ Different in OO.o ...

	+ OO.o has no:
	      gtk_im_context_set_cursor_location (entry->im_context, &area);

	      There is SalI18N_InputContext::UpdateSpotLocation which does what
	      gtk_im_context_set_cursor_location does for xim.
	      
	+ Press <shift>-<space> - nothing happens
		+ Alt tab twice - suddenly it works
			+ some event emission / association not
			  happening correctly
		+ [ FocusIn ? before SetInputContext ? ]
	  

<maiku> There are different input styles:
<michael> ok;
<michael> so - we don't even toggle the keybinding thing
<maiku> 1) Overthespot: you input the あ in an extra window, after RETURN it is pasted into the application. The extra window is sometimes at weird positons.
<michael> ok;
<maiku> 2) OnTheSpot: you input the あ directly into the application. 
<michael> so - you can configure those in the settings somewhere ?
<maiku> In the scim setup menu.
<michael> so - to get this right; 'OnTheSpot' would insert some glyphs into the app, and then change them as you type more, and you would see no pop-up menu ?
<michael> s/pop-up menu/pop-up editing window/
<maiku> With OnTheSpot you see the scim panel, but no extra window as you type characters.
<maiku> The characters are directly inserted into the application and changed as you type more.
<michael> and does it wait until the character is complete before inserting it ?
<maiku> No, every keystroke is inserted immediately. 
<michael> so - the API provides a way to go back and remove / update previous characters right ?
<maiku> But if it is not complete yet, it is marked somehow. Maybe underlined or a different color.
<michael> this is extremely helpful :-)
<michael> thanks so much.

<maiku> I.e. you input "nihonn"
<maiku> That is immediately converted to にほん
<maiku> You don't press return then but Space instead.
<maiku> Space means "convert to Chinese characters". If you press Space you get 二本 which means "Japan"
<maiku> If the first conversion is not right (usually phonetics -> Chinese characters is not a unique conversion) you press Space again.
scim-gtk2-immodule-1.0.1-1.1
<maiku> Then you get another choice. If it still isn't right you keep pressing Space and get a selection box of all possibilities.

<michael> how does that interaction work - does the app register itself with xim ? or is it stolen at the Xserver level ?
* michael is still on GTK_IM_MODULE=scim
<maiku> The app calls some Xlib functions like XOpenIM().

** The problem:

<maiku> 1.4 is difficult to reproduce. Maybe I should better write instructions how to reproduce it 100% in Bugzilla, you know now how it works.
<maiku> Now the worse problem with GTK_IM_MODULE=scim.
<maiku> If you have 
<maiku> GTK_IM_MODULE=scim XMODIFIERS=@im=SCIM OOo
<maiku> you couldn't open the input method with Shift+Space at all.
<maiku> That was also in Takashi's bug report.
<maiku> Start OOo with 
<maiku> GTK_IM_MODULE=scim XMODIFIERS=@im=SCIM OOo
<maiku> verify that Shift+Space does nothing.
<maiku> verify that Shift+Space does nothing in oowriter.
<maiku> Now open a spread sheet from the file menu. In the spread sheet you can now activate the input in the entry widget above the table.
<maiku> Close the spread sheet again.
<maiku> Now you can activate the input in oowriter!!!
<maiku> Trying this once in the spread sheet made it work in oowriter.
<maiku> Surprising. 
<maiku> Apparently only one window at a time can have the input activated.
<maiku> I cannot reproduce this problem on my x86_64. On my x86_64, the
<maiku> behavior for GTK_IM_MODULE=scim is the same as for GTK_IM_MODULE=xim.
<maiku> In both cases, XIM is apparently used on x86_64.
<maiku> GTK_IM_MODULE=scim works fine on x86_64 with 64 bit applications like gedit.
<maiku> But OOo is a 32 bit application. I guess this is the reason why GTK_IM_MODULE=scim doesn't work or OOo on x86_64.
<maiku> Probably 32bit plugins for the input modules would be needed and they are not there.
<michael> :-)
<michael> yes; I can well believe that is the case,
<maiku> Removing OpenOffice_org-gnome solves problems 1.3 and 1.4.

** What is an IM module ?

gtk+:
    gtk modules better than XIM modules:

    + GTK_IM_MODULE=scim
	+ brokenness all over
    + GTK_IM_MODULE=xim ( set XMODIFIERS=@im=scim )
    + GTK_IM_MODULE=uim

XIM
    + worse but backwards compatible
    + scim
	+ OnTheSpot - dodgy / broken
	+ OverTheSpot - works fine
    + kinput2
	+ works perfectly

SCIM - 
    + works with gtk+ and XIM

UIM - Universal Input Method
    + works with gtk+ and XIM

    "In most GTK+ 2 programs you'll be able to select UIM by
     right-clicking on a text input field without using any special
     setup. However, if you'd like to use it in the old X Input Method
     interface, you should install SCIM in addition to UIM. If your
     only aim is to use Japanese input methods, you could also use the
     helper application uim-xim."

    "UIM is activated by pressing shift + space. For more
     information, have a look at UIM's home page and wiki."

    export GTK_IM_MODULE=uim
    export XMODIFIERS=@im=uim
    exec uim-xim&

    ** Native OO.o XIM - use shift-space not ctrl-space **

** Links:
    Linux i18n howto: http://home.no.net/david/i18n.php
    UIM: http://uim.freedesktop.org/


** TODO:
   what are IIIMF / UIM ?
