Community
Participate
Working Groups
This problem has been separated from Bugzilla39881. We need public APIs to control IME. BidiUtil class has the following APIs but the class currently exists in an internal package. This must be exposed to public. - isBidiPlatform() - addLanguageListener() - removeLanguageListener() - getKeyboardLanguage() - getKeyboardLanguageList() - setKeyboardLanguage()
We tried to get rid of BidiUtil for 3.0 but ran out of time. FH, is there already a bug report for this?
NOTE. Some of us out there use BidiUtil - although internal, it was the only way to implement bidi functions, and was used as per Eclipse's own recommendation. Should not eliminate it (when the time comes), but just deprecate it for a while!!
*** Bug 85953 has been marked as a duplicate of this bug. ***
*** Bug 74783 has been marked as a duplicate of this bug. ***
Please consider for Ganymede
*** Bug 156052 has been marked as a duplicate of this bug. ***
Bug 156052 has a few more suggestions for API.
I think we need some more APIs in order to get a better BIDI ecperience for the users. I propose to add these methods, to the API: 1. globalOrientationChanged() - (Listener event), Global Orientation is important too, we need to be aware of it, and not have to the current lang on a timely basis, or every time we need to write a character. in windows GO changes when you hit CTRL + LEFT/Right shift (Just as an example, on a BIDI keyborad) 2. isLangRTL(Lang lang) - Again, need to have a central place/API to ask if the lang should be treated as RTL or LTR 3. isKeyboardSelectedLangRTL() - Simplification, to check the current selected lang if it is RTL/LTR
156052 was closed out as DUP of this one. Any plans to fix it in 3.4?
(In reply to comment #9) > 156052 was closed out as DUP of this one. Any plans to fix it in 3.4? Sorry, we are past the API freeze. I know GTK doesn't API for this, we could by pass GTK and call XKB directly but that would cause integration problems with another apps in the desktop. It would not work well. In Carbon I don't know what they have. In Windows I believe we can implement all the APIs requested.
>BidiUtil#isBidiPlatform() Would be good enough for me. Currently this blocks me from fixing the BIDI bug 54942.
>BidiUtil#isBidiPlatform() As far as I remember, "isBidiPlatform" was decided based on availability of a Bidi input locale / keyboard layout. Is it still okay? (I think clients rather expect querying of the native rendering Bidi capabilities.)
And there could be yet another method to detect the presence of RTL keyboard language (e.g. required for bug 54942).
(In reply to comment #12) > >BidiUtil#isBidiPlatform() > As far as I remember, "isBidiPlatform" was decided based on availability of a > Bidi input locale / keyboard layout. Is it still okay? Yes, that is StyledText policy to enable bidi caret. I don't think we can change this. > (I think clients rather expect querying of the native rendering Bidi > capabilities.) What does "native rendering Bidi capabilities" mean ? On windows, WINVER > 4.10 supports mirroring. Bidi text rendering has being around for a long time. Maybe this what you are looking for: http://blogs.msdn.com/michkap/archive/2006/03/03/542963.aspx Maybe this could be used to enable bidi segments listener of StyledText. Right now it runs when this is true: IS_GTK || IS_CARBON || BidiUtil.isBidiPlatform() || isMirrored;
(In reply to comment #12) > What does "native rendering Bidi capabilities" mean ? Actually I meant any characteristic that would affect our decision to enable Bidi support in application or the toolkit itself. I think the notion "Bidi platform" is usually associated with the *text* reordering capabilities. But it's hardly possible to work out a single universal criteria which covers the entire variety of client needs and the respective "native capabilities". Fortunately, the latter is rather limited, and can likely be addressed well... Perhaps |isBidiPlatform| can be parameterized to get notified of the Bidi aspect(s) to look at? E.g.: - isBidiPlatform(BIDI_KEYBOARD) - isBidiPlatform(BIDI_LOCALE) - isBidiPlatform(BIDI_MIRROR) - isBidiPlatform(BIDI_REORDER) - will need a (stock) font - isBidiPlatform(BIDI_SHAPE) - ditto - isBidiPlatform(BIDI_REORDER | BIDI_SHAPE | BIDI_MIRROR), - etc. Of course that would turn it into non-IME-specific method (and maybe even not SWT-specific one ;-) ).
(In reply to comment #14) > > Maybe this could be used to enable bidi segments listener of StyledText. Right > now it runs when this is true: > IS_GTK || IS_CARBON || BidiUtil.isBidiPlatform() || isMirrored; > I think Bidi segments should get enabled when basic text reordering occurs (i.e. isBidiPlatform(BIDI_REORDER) is satisfied - but of course regardless of the fact if provided by that API or not). I used another method for its detection, and can reference it here if necessary.
*** Bug 233898 has been marked as a duplicate of this bug. ***
*** Bug 238004 has been marked as a duplicate of this bug. ***
Created attachment 105828 [details] Example of setting and getting keyboard language on *nix via XKB A very rough prototype of how set/getKeyboardLanguage could be implemented in gtk using X Keyboard Extension. There are not few issues/concerns/questions around, which I'll try to summarize tomorrow. ____________ To compile: gcc -lX11 -L/usr/lib -I/usr/include -o kbdtest kbdtest.c Usage: kbdtest [OPTION] [LANG] OPTION: -c default: clean up (for now sets English with Arabic and Hebrew enabled as well) -g get keyboard language\n"); -s set keyboard language\n"); --help print this help\n"); LANG: language ID Example: kbdtest -g (query current language) kbdtest -s il (set Hebrew) kbdtest -s ara (set Arabic) kbdtest -c (clean)
Created attachment 105877 [details] Example of set/get keyboard language on *nix via XKB Sorry: there was seemingly a weird problem compiling strcat calls, so the example used workarounds. The problem was elsewhere. I resubmit the example with some corrections.
Created attachment 105878 [details] Example of set/get keyboard language on *nix via XKB Sorry: there was seemingly a weird problem compiling strcat calls, so the example used workarounds. The problem was elsewhere. I resubmit the example with some corrections.
GTK doesn't provide sufficient (in the context of this bug) API to interoperate with IM. Thus for the moment I do not see an alternative to making direct X11 API calls. Among other things, that would require introducing quite a considerable amount of new SWT natives (apparently invoked through dynamic lazy loading). Felipe, can you please indicate if you see any problem with that?
For isBidiPlatform() solely (in its current interpretation), we'll only need 2 gtk functions: (1) gdk_keymap_get_direction (2) gdk_keymap_have_bidi_layouts We will first call (1). If it returns RTL, the keyboard is doubtlessly Bidi-enabled. Otherwise, we will also call (2) and just get to clients whatever it returns. (Lone (2) seems insufficient, since it indicates |False| for any unidirectional set of languages, including RTL ones).
Okay, It has been years since the last time I worked on GTK. I wrote a bunch of XKB code (similar to Lina's) that got mostly of the APIs working. Where it failed bad was in the integration with other desktop applications, mainly the GNOME and KDE applets for switching keyboard layout. Here an example for getKeyboardLanguageList() This list can be store in XKB and it can be retrieve using XKB calls. But the GNOME applet doesn't keep the list of layout in XKB, it has its own list. the KDE does the same thing. Mostly users don't use XKB directly, they use the applet. So writting code that works for XKB but doesn't work with the applets will not fix the bug for mostly users. setKeyboardLanguage() is even worse. It changes the layout 'behind the scenes' cause the applet to be out of sync (e.i the applet shows EN but the keyboard is really in IL). Note: gdk_keymap_have_bidi_layouts () says: Since 2.12 That is pretty new API. Note: This conclusion were made back a while ago. We need to find out if: (a) those applets have changed to better integrate with other XKB applications (b) their offer API we can use
Interoperability with keyboard switching tools is one of the major issues I also have in mind. KDE. Commonly used switcher - kxkb - can be manipulated via DCOP interfaces (not XKB directly). kxkb provides the following API critical to us ('$ dcop kxkb kxkb'): - setLayout(QString) - QString getCurrentLayout() - QStringList getLayoutList() These seem to work fine, e.g. '$dcop kxkb kxkb setLayout il' not only loads Hebrew keyboard mapping, but also makes the applet icon change accordingly. GNOME. Its keymap switcher ('gswitchit', I think) seems to be listening for keymap events and was reacting adequately during the testing. I have also written and run in GNOME tests using libxklavier library: http://xlibs.freedesktop.org/xkbdesc/doc/ Libxklavier wraps around XKB, providing higher-level APIs for keyboard manipulation. Perhaps using it is preferable to making direct XKB calls. As far as I understand, it ships at least with all those Linux distributions that offer gswitchit, consuming this library. Of course, there can be more tools whose behavior is unpredictable. In particular, as far as I know, for languages actually using IME (e.g. Chinese, Japanese, Korean) there are other, dedicated tools. I am currently trying to get more information on those other tools. I think we should only address broadly used ones.
I did some research on linux today. Gnome switcher: Gnome switcher 'gswitchit' (http://gswitchit.sourceforge.net/) now is part of the gnome-applets, I couldn't find a homepage for it but you can get the code at gnome SVN: http://developer.gnome.org/tools/svn.html LibXklavier http://www.freedesktop.org/wiki/Software/LibXklavier I'm not sure if I would like add a dependency on this library. I'm okay if we only work on XFree86. D-Bus http://www.freedesktop.org/wiki/Software/dbus http://en.wikipedia.org/wiki/D-Bus http://library.gnome.org/devel/dbus-glib/unstable/index.html According to what I read this is the right technology to use for communication between process. in our case, eclipse-gswitchit and eclipse-kxkb. KDE 4 has replaced DCOP with D-BUS and GNOME is also uses D-BUS. We need to find out if gswitchit and kxkb use D-Bus.
Back from vacation... _________________ There was also a private communication thread, which, by mutual agreement of the sides and after a minor clean up, I'm posting here. _________________ Lina on Jul 10: Basically, get/setKeyboardLanguage and getKeyboardLanguageList seem to work for me with GNOME (gswitchit) and KDE (kxkb) applets. I tried various methods. I am still not sure which one is preferable. Attached is my last version of getKeyboardLanguageList. I included one API only to provide just high view of the changes. Please do not do a thorough review. There are quite many TODOs yet, and it doesn't worth putting any significant time and effort. Please can you just let me know your overall impression of the strategy. Bulk of code is native. Each native function is "custom", including series of actual native calls. E.g. the native for getKeyboardLanguageList is doing the following: (1) Tries to use DCOP first: - runs dcop command (this could be also done through C++ calls or Java - via Runtime#exec()), - streams the output to a file, - reads the file content into returned memory block. (2) If nothing got streamed out, it invokes XKB functions, like those we used in the past. The return values of (1) and (2) are currently in mismatching formats (short vs. long layout names). Should we sync this with win32? What data type win32's getKeyboardLanguageList counterpart will return? an integer array? As for the Java changes, I intended to create a new class, named say IMEUtil or KeyboardUtil, but was not sure about the name. This doesn't seem a real issue though. For the time being, the changes are added to the old BidiUtil. _________________ Felipe on Jul 14: I read the code (didn't compile it, didn't run it, just read it). Here my thoughts: 1- I really don't like the idea of new library (swt-ime) 2- We should use D-Bus (dcop is becoming deprecated, see KDE 4) 3- I guess it should be okay to include X11/XKBlib.h (if we make all calls dynamic we prop won't need to include anything) 4- I think we will have legal problems to include kde/kapplication.h
Created attachment 107886 [details] IME API attempt #1 Experimental code referenced in comment 27.
(kde/kapplication.h related part is removed for legal reasons, as per Felipe's comments.)
Felipe, regarding using D-Bus in KDE (and possibly GNOME): It looks like KDE 4 has not yet been adopted by many Linux distributions. Examples of distros that ship KDE 4 are: - Fedora 9 (http://distrowatch.com/table.php?distribution=fedora) - OpenSuSE 11 (http://distrowatch.com/table.php?distribution=suse) - Ubuntu X (?) (http://distrowatch.com/table.php?distribution=ubuntu) Examples of distros that do NOT ship KDE 4 are: - Debian (http://distrowatch.com/table.php?distribution=debian) - Gentoo (http://distrowatch.com/table.php?distribution=gentoo) - Mandriva (http://distrowatch.com/table.php?distribution=mandriva) - RHEL (http://distrowatch.com/table.php?distribution=redhat) - Slackware (http://distrowatch.com/table.php?distribution=slackware) - Turbolinux (http://distrowatch.com/table.php?distribution=turbolinux) So it may be too early to rely on D-Bus (or exclusively on D-Bus). For the intermediate future at least, it seems we need to have a DCOP-based solution available.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
