ibus 1.3.x conflicts

[luojie-dune]

http://code.google.com/p/ibus/issues/detail?id=897#c4

What version of the product are you using? On what operating system?
Ubuntu Lucid x86/AMD64
IBus version: 1.3.X

call kupfer and type

and found:

kupfer can't identify typings- as most keys not functional

This bug is probably from ibus but might be kupfer's problem.

[X (u78qir8a9-deactivatedaccount)]

Kupfer uses a normal GTK+ Text Entry, although it is hidden. I can't test ibex. Please comment on the following:

* How does it work in text mode (Type Ctrl+. to toggle). Does text mode toggle? Can you type in text mode?

* You can set the input method if you open the text entry menu. Normally you open the menu with Shift+F10, then you select the input method. Can you get Kupfer to work this way?

[luojie-dune (luojie-dune)]

Everything in normal way, except I did modify the toggle keys for both
"kupfer" via super+space and "ibus" via alt+x.

It works with ibus-1.2.X, but raise when using ibus-1.3.x.

The point is on ibus, neither English nor other language type work well,
sometimes press a few keys then one work out for kupfer, while pressing one
keys for multiple times it won't come out in kupfer window.

I don't quite understand the questions below, so I can't answer... [?]

* You can set the input method if you open the text entry menu (whats
this...). Normally
you open the menu with Shift+F10(whats this...), then you select the input
method. Can
you get Kupfer to work this way?

But the fact is just with ibus-daemon running, kuper cannot work properly.

So ibus engine conflicts with kupfer?

Regards

Jie LUO

On 6 July 2010 08:04, Ulrik Sverdrup <email address hidden> wrote:

> Kupfer uses a normal GTK+ Text Entry, although it is hidden. I can't
> test ibex. Please comment on the following:
>
> * How does it work in text mode (Type Ctrl+. to toggle). Does text mode
> toggle? Can you type in text mode?
>
> * You can set the input method if you open the text entry menu. Normally
> you open the menu with Shift+F10, then you select the input method. Can
> you get Kupfer to work this way?
>
> --
> ibus 1.3.x conflicts
> https://bugs.launchpad.net/bugs/601816
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[LI Daobing (lidaobing)]

can you have a look on https://bugzilla.gnome.org/show_bug.cgi?id=621659

gnome-shell has a similar problem, which can not type under ibus,

[David Schneider (dnschneid)]

I proposed a possible patch for this issue in bug 630490.

[X (u78qir8a9-deactivatedaccount)]

This is my proposed patch! A oneliner to set Kupfer to the "simple" input manager when we start. I think the user may choose another input manager if you press Shift+F10 when Kupfer is active.

Thoughts? Does it work? (please try the patch on top of a fresh clone of Kupfer!) Should we handle text mode and non-text-mode differently?

[David Schneider (dnschneid)]

In response to bug 630490 comment 7 ( https://bugs.launchpad.net/kupfer/+bug/630490/comments/7 ):
Indeed, my hacky patch only accepts ascii (as those are the only characters trivially and reliably processable), so allowing GTK to properly process the keystrokes would be much better.
ibus does break return and backspace, which is why they are specially handled. Basically, ibus swallows everything.

In my opinion, the usage of the hidden text box as the input in non-text-mode is more of a programmatic convenience than anything else--the UI in that mode does not work well with IMEs. However, should the user pop open the text mode, they should expect their default IME to do its thing.

So I can see two options, depending on your view as to the role of the non-text mode:
If you see non-text-mode as a quick way to get to "common" things with standard filenames, then the simple IME idea works well (or my patch, I suppose, but your way is much cleaner). We can force the "simple" input manager when the input box is hidden and restore the IME when text mode is visible (I'll test your patch shortly). This should get rid of the weird IME interaction when the box is hidden. If the user wishes to look up something that requires an IME, they have to pop open the text mode box, at which point they lose the smart searching features.
If you see non-text-mode as the standard interface for everything except for things requiring pure text input (e.g. web addresses), then we need to get the IME working in non-text-mode. Before Maverick, ibus (and uim), when in non-text mode do not have a visible pre-edit box, but could still inject characters into the non-text-mode. I'm not well-versed in GTK+, but there might be a signal you can latch onto when a pre-edit box is to be shown, at which case you could do...something...such that the pre-edit box appears in the right place. This way you can use the smart search with any character in unicode, which would be nice (I use it myself, even though I can't see the pre-edit box).

I have since replaced ibus with uim on my system (due to ibus being completely broken in maverick for me, and uim being much nicer). I'll see what I can figure out running uim. luojie-dune, if you get the chance, please test Ulrik's patch as well and see if it fixes the issue with ibus.

[David Schneider (dnschneid)]

Here's a sample implementation of the first option (simple-ime for non-text mode, ime for text-mode).
The only caveat with that patch is that if you manually switch IMEs, it will reset it the next time you open text mode.

UIM doesn't have the same issue that ibus does with eating the characters, it seems, but I would imagine that this fixes it, as I can't even activate UIM when not in text mode.

[X (u78qir8a9-deactivatedaccount)]

My patch did the same thing that your new patch does, except for switching in text-mode/non-text mode.

Using GtkEntry but hidden surely is a convenience, it's a huge convenience -- we get GTK to handle most of all the difficult international text issues. Maybe the best way forward would be 1) To enforce "simple" input when the entry is hidden and 2) An option to always show the text field, so that it can be used for IM inputs.

[David Schneider (dnschneid)]

Sorry I wasn't clear. The patch I posted was an extension of yours.

As for always showing the text field, how would you differentiate between text and non-text modes?
Another possibility would be to have the option of having another, small entry widget floating in the bottom-left corner of the window in non-text mode, the difference being that every time it detects entry (e.g. from normal input or IME commits) it immediately forwards it to the hidden entry and clears itself. It would basically behave lake a small pre-edit box for non-text mode. You can even change the background color of the edit box to match what is under it. If you remove the border on the box as well, the user will not even notice it unless he or she is using an IME, so you may not even have to make it an option. Does that make sense?

[David Schneider (dnschneid)]

Attached is a function implementation of the idea above. I had to do the hacky backspace code again, but everything else (like return and whatnot) is implemented normally.
Unfortunately, I do not have the experience in GTK to actually make it look pretty. Ideally that preedit box would not be in the vbox, but instead would be small (five or so full-width characters max...unless you can make it auto-sizing?) and floating in the currently selected search pane with its background matched/transparent and no cursor showing such that you don't even notice it is there (unless of course you start doing an IME pre-edit).

Ulrik, do you think you can make it look good?

[David Schneider (dnschneid)]

Attached is a much prettier version of the above. The major issue remaining is the centering of the match label; otherwise it works well and looks pretty good.

[David Schneider (dnschneid)]

Turns out that the Entry widget emits a preedit-changed signal, so latching onto that we can dynamically change the width of the preedit box.
The attached patch does just that. If you do not use an IME, it behaves exactly the same as normal kupfer. If you start to type using an IME, the preedit box pops out. Once you commit, the box hides again.

It works quite nicely for me with uim; we need someone to confirm with ibus.

If this works for everyone, then I recommend this patch as it is (baring any cleanups/restructures you suggest, of course).

[David Schneider (dnschneid)]

Sorry for the flurry of posts.
This last patch fixes one instance where the width does not reset itself, and adopts a slightly lazier hiding scheme so that the preedit doesn't repeatedly change size if you are doing multiple IM-based entries at once.

[David Schneider (dnschneid)]

Here's the patch relative to the latest version of kupfer. I also fixed a bug with the text entry being selected when it appears (particularly annoying when hitting = to do a calculation).

[David Schneider (dnschneid)]

This patch also keeps the slow input timer reset when preedit changes.

[David Schneider (dnschneid)]

Ulrik, is there anything I need to do to improve on in the patch posted above? I've been using it the past two and a half months and haven't had any issues. It looks clean, it uses the input box to process text, and it allows for pre-edit in non-text mode. It also gets rid of that one pixel row at the bottom of the window that another bug was complaining about.
I would appreciate you checking it out and letting me know if it needs any adjustment.
Thanks!

[X (u78qir8a9-deactivatedaccount)]

David, I'm sorry that I haven't looked at this for such a long time, just like much of Kupfer. But I also came back to this bug last :-( hehe.. now, to business.

The patch looks good, but I have not been able to test the preedit functionality. I have installed ibus. How do I set it up to try?

Ok, now it certainly is *not* your fault that I have written messy, messy code in kupfer/ui/browser.py. This is the worst part of Kupfer.

Still, letting self.preedit thing ride on the set_active call felt strange.. No wonder it took me a while to understand that, the whole set_active/set_state stuff is superfluous anyway. I've produced an updated patch against today's master that uses a more explicit inject_preedit call. That also fixed up the changes in highlighting.

So then the important question is,
1) Does the patch still fulfill its purpose (with ibus) after my changes?
2) Does everything work like normal for other users (it definitiely seems like it)

Thanks for contributing this anyway, maybe some have already used it

[X (u78qir8a9-deactivatedaccount)]

I did not get ibus to do anything yet, but I did make the preedit thing show up :-) So with my changes it didn't correctly collapse with the previous patch, so new one updated attached (one line difference)

[David Schneider (dnschneid)]

Not a problem! My patch has been working fine for me, so I was just concerned if it would make it to master so others could use it too :)

Thanks for cleaning up the code; it certainly is more understandable now.

With your second patch, everything seems to be working fine with uim. I don't have ibus to try it with right now, but if you have the ibus framework set up, you'll want the ibus-anthy package (on Debian/Ubuntu, at least) so that you can enable the Anthy Japanese IME. When you enable that you'll get a preedit-based input method which will hopefully appear nicely in Kupfer's preedit box, and not just fail miserably as it used to. If I recall, ibus wasn't working whether or not Anthy was enabled, so you might need to play around with the different ibus/Anthy states to figure out if everything is truly working now.

Thanks again for looking into this!

[David Schneider (dnschneid)]

Oops, it looks like your patch causes the cursor to move to the beginning when textmode is activated by = or /

Haven't looked into the cause, but I'm sure it's a one-line change somewhere...

[X (u78qir8a9-deactivatedaccount)]

David, I think I already fixed the cursor position issue, I made it always do self.entry.set_position(-1) when moving text from preedit to the Text Entry. I think your patch works really well. I have not gotten Anthy and ibus to work at all, nothing happens simply and it doesn't show up. I can use other included input modes (via GTK) and they use the preedit field just fine.

latest version of the patch is at github on branch ibus https://github.com/engla/kupfer/commits/ibus I'll merge this into master right after this weeks release.

[David Schneider (dnschneid)]

Awesome.

Yeah, Anthy by default is probably in "raw input" mode, where no box shows up. In the ibus or anthy toolbar (whichever shows up, I forget), is there an icon that looks like " _A "? That means it's in raw text mode. Click on that and change it to "hiragana", or "あ". Hopefully you'll get something out of it then.

[X (u78qir8a9-deactivatedaccount)]

David, your patch is merged to master, and it's in there in the stream with a lot of UI changes. There is a very slight miscoloration under the preedit field at the moment, but I will get to it later. I need someone with ibus to test the current development version (master branch).

[David Schneider (dnschneid)]

Okay, so I reinstalled ibus and pulled master (whoa, ui changes).
It looks like ibus support is only half-fixed. Raw text input (without any IME) still gets ignored, although if you smash on the keyboard enough a couple keypresses do get through. If you enable Anthy or whatever IME, the preedit works properly and the text input gets processed correctly. So this IS improvement on the old behavior, but still unacceptable. I'll poke around and see what I can come up with.

[David Schneider (dnschneid)]

After a bunch of searching about poking at the IMContext and turning up nothing, I took a wild stab and told the keypress event to always return false.
And ibus worked.

Some more debugging and it turns out that for whatever reason, ibus generates an extra keypress event for each letter pressed. The second event is caught by the "held key" detection feature of Kupfer (for launching default actions) and is getting swallowed.

Printing out keypress events, it looks like this:
Under uim:
<gtk.gdk.Event at 0xa78eb30: GDK_KEY_PRESS keyval=a>
<gtk.gdk.Event at 0xa78e560: GDK_KEY_PRESS keyval=s>
<gtk.gdk.Event at 0xa6e0338: GDK_KEY_PRESS keyval=d>
<gtk.gdk.Event at 0xa6e0e18: GDK_KEY_PRESS keyval=f>

Under ibus:
<gtk.gdk.Event at 0xa6e0e18: GDK_KEY_PRESS keyval=d>
<gtk.gdk.Event at 0xa6e0e18: GDK_KEY_PRESS keyval=d>
<gtk.gdk.Event at 0xa597f80: GDK_KEY_PRESS keyval=j>
<gtk.gdk.Event at 0xa597f80: GDK_KEY_PRESS keyval=j>
<gtk.gdk.Event at 0xa78e830: GDK_KEY_PRESS keyval=n>
<gtk.gdk.Event at 0xa597f80: GDK_KEY_PRESS keyval=n>

So basically, disabling repeat detection (under the "# activate on repeated key" comment) fixes ibus.
I'll see if I can figure out a heuristic so that both ibus and the repeat key feature works.

[David Schneider (dnschneid)]

Since the time between the two events appears to be on the order of 1 to 5 ms, attached is a patch that puts a minimum threshold on the repeat time.
I have it set to 20ms, which is very safe for making sure ibus keypresses get through, although it will break things for people who have their repeat rate set to 50 Hz.
The ideal patch would compare the delay to the current X11 repeat rate setting, but this gets things working.

[X (u78qir8a9-deactivatedaccount)]

great work! IMO it is no big loss if we just remove the held key detection. It's an experiment that is never used (it's not documented), and it behaved differently with different gtk versions (and I didn't understand why).

[David Schneider (dnschneid)]

I've never really used it myself (except accidentally), and when I have tried to use it, I tend to blast characters into whatever I launched. Should that feature be kept, I'd suggest making it wait until you release the key before actually executing the action. That is, held key -> action-to-be-executed is visually selected -> release key -> action is executed.

But that's kind of irrelevant for here. If you want to keep it around a bit longer, that patch makes it and ibus coexist nicely, or you can just dump the feature.

[X (u78qir8a9-deactivatedaccount)]

I have committed your patch, thanks a lot.

[X (u78qir8a9-deactivatedaccount)]

This is fixed, right? The background color is postponed for later, I'm not sure it can be fixed with a window that is partially transparent.

[David Schneider (dnschneid)]

Yep, everything seems fine; there are no issues with ibus, and the preedit works.
As for looks, the color seems to be okay with the dark theme enabled. Also, it's kind of neat that the preedit, when visible, squares out the corner of the pane it is enabled on. Kind of a nice visual feedback to let you know that it is activated, actually.