|
|
|
I wrote a set of patches that demonstrates what we can do with good old XIM. I had to change both SDL and SL viewer (mostly LLwindowSDL class). It is available here ( http://alissa-sabre.cocolog-nifty.com/files/ots-20071008.tar.bz2
 ) if you are interested.
Based on this experience, I concluded that this (i.e., SDL + XIM) is not the way to go. I agree we somehow switch to a modern input method interface. Although I'm still not 100% confortable with GTK immodule API, I have to agree that it is certainly a good candidate, especially provided that there are no better alternative available on Linux... I made some progress on this issue and produced a patch kit.
The file GTK-20071111.tar.bz2 contains the work in progess as a form of a patch against SL viewer 1.18.4.3. It replaces SDL with GtkGLExt to support GTK immodules. Detailed build information is included in the archive. I think the patch kit is not suitable for merge into SL viewer's development branch yet, so I don't mark "Patch Attached" at this moment. I'm attaching my latest work on this issue as a patch: gtk-20071201.patch
This patch is against 1.18.5.3 source files. You first need to apply the patch ime-20071201.patch attached to See README contained in the gtk-20071111.tar.bz2 patch kit for other build details. (The patch files included in the gtk-20071111.tar.bz2 should not be applied when using gtk-20071201.patch.) If you just want to try the patched viewer without compiling, you can download the binary from my site. It is available as: http://alissa-sabre.cocolog-nifty.com/files/gtk-20071201-Linux.tar.bz2 Have fun. Well, I'm uploading another monthly_update of GTK immodule project. This patch, gtk-20080113.patch is against the 1.19.0 beta (76838) source. It now supports fullscreen resolution changes and adjustment of gamma correction value. No big changes on immodule handling. It still doesn't wok under a locale whose decimal point is not a period.
Have fun. Has anyone taken a look at Clutter? http://www.clutter-project.org/
It appears to be a close relative of Gtk+, and might be a more suitable solution. Rob, against what do you think Clutter is a "more suitalbe solution"? Correct me if I'm wrong, but I believe the current clutter lacks support for input method handling. Adapting it doesn't solve the problem that Japanese or Chinese speaker's problems.
I updated the patch of the series. It is against 1.19.0.4. No big changes. Only small changes other than adapting to the latest viewer source. I believe I did all I can do. It have no further plan on this issue. It is up to LL's decision to take this patch or just trash it...
In this version (20080301), added an alternative workaround for locale issue (known as SL-13243) in wrapper.sh (the "secondlife" shell script), so that a user can start the viewer under a locale whose decimal digit is different from C locale. (We need to run GTK event loop under the user's prefered locale so that input methods work.) This is the biggest development in this version of the patch. As always, it is not easy to produce an executable with this patch. You need more recent GTK than that contained in LL library bundle. It means you need to update other dependencies, too. It will be easier to follow STANDALONE build procedure described on the SL wiki than to replace files under linden/libraries directory. You will need slviewer-1.18.5.1-standalone_expat_includes.patch for I used Fedora 8 x86 and g++ 3.4 for development. Have fun. I checked "Patch attached" since I believe the 20080301 version of the patch is stable enough for integration.
Thanks, Alissa.
I'm attaching a version of the same patch (minus SConstruct changes) with the conflicts resolved against the current release (~1.19.1RC). Verified in 1.20.7 (87883) running Ubuntu Hardy Heron (8.04) that I am able to input Japanese (including Kanji) using XIM / Anthy. I am able to access the input field which pastes to the chat line in the viewer.
Kazunori, the japanese input DOES work but it is messy. In other software and OSes, it is done directly in the software window, "inline", and you can access the IME options. But the client as it is right now doesn't do that, the input is done in an external window then it is pasted to the client. That's what this feature request is about.
As a side effect here I'm experiencing bug VWR-6212 . Hi Alissa,
Would you mind turning this into a LLWindowGTK which co-exists in the code with LLWindowSDL? Keeping both options around in the code for a while will really help to make the transition gentle. (And, I suspect, the final iteration may turn out to be a hybrid.) I wonder, how would you feel about maintaining this in a sandbox in the public svn tree? @Alissa - pinging on the above, in case the last was missed
I updated my GTK patch. The new one is gtk-20081221.diff. It includes necessary changes to cmake files, too.
Major changes from 20080301/20080304 version are:
To compile the patched viewer, you need GtkGLExt header files under linde/libraries. (Or, you could do standalone build.) Please make sure you GTK header file versions are compatible with GtkGLExt's. When I build it, I copy distro supplied GTK related header files in /usr/include to appropriate directories under linde/libraries, overwriting LL supplied develop.py downloaded ones. Yes, there should be a better way. I'm too lazy to seek for one. Have fun. Thanks, Alissa, interesting reading.
A few comments:
Feel free to clean up the poor semantics, uncertain comments and hackery of LLWindowSDL in your own LLWindowGTK instead of cloning it all over; LLWindowSDL has had many authors over time and grown organically - it's a stinking mess of coding styles, hackery and fuzzy semantics but it works (apart from good i18n support of course) which is why it doesn't get much cleanup. Tofu,
> Some methods are identical or very similar between LLWindowSDL vs GTK - probably these belong either in a common superclass or (easiest) common helper-code. Yes, if we keep both forever. However, I expect that LLWindowSDL to disappear really soon. I'm relactant to make such changes for the moment. > Runtime selection of SDL vs GTK is interesting but compile-time selection is still more desirable - that would make this mergeable sooner so, pragmatically, the distro-specific SL builds can start enabling GTK-only and we can get wider testing feedback before this gets enabled at all in Linden builds. It is straight forward to make SDL-GtkGL switching a compile option, because LLWindow class uses the factory pattern (It's a Linden's feat, of course), and my LLWindowGTK is yet another subclass implementation of LLWindow. A patch, gtk-20081228.diff, is attached. It is against my gtk-20081221. The macro LL_SDL is for LLWindowSDL, and LL_GTKGL is for LLWindowGTK. (I didn't use LL_GTK for the purpose, because it is essentially for "SDL with GTK dialog boxes.") If you define both LL_SDL and LL_GTKGL, the runtime swithing is compiled. Selection of LL_SDL only, LL_GTKGL only, and both LL_SDL and LL_GTKGL is currently by manual editing of cmake/LLWindow.cmake. I have a feeling the selection should be through develop.py, although I have no idea how I can do so. > Please base patches on maint-viewer if you can - this is where Linux-specific changes (mostly) happen first. So, this is where this is most likely to land and it's the branch with the most GTK/SDL changes to sync/conflict against (for example, current maint-viewer has some copy-and-paste changes to support PRIMARY clipboard). I'm considering that. Hi - This should still be rebased against maint-viewer (or actually trunk at this point is fine). The requirement for a recent GTK and the uncommon GTKGLEXT is still a sticking-point - some users are definitely happily using distros without these - can you think of a workaround? One possibility is, we're probably going to be shipping a version of Qt 4.5 with future viewers, and Qt natively supports setting up GL contexts and probably everything else we need (right?), though that's a comparable amount of work again.
Tofu, if you want a good advice, stay away from Qt. Ever since I started using Linux, every time I try a Qt-based application, I have problems with its internationalization support: Japanese text displayed as ????????, keyboard dead keys (for French accentuated letters) not working, etc, etc. As someone who uses both Japanese and French in SL, those two are very important for me. GTK is the way to go for internationalization. I never have any trouble with GTK-based applications.
Today as QAvimator, which uses the Qt libray to run, crashed when I tried to open a file from a folder containing non-latin characters, I remembered about my March 12th comment... It's as I said. Problems, problems, problems.
Do these problems still apply to Qt 4.5? Thanks.
I don't have that version of Qt. I have 4.2.3. I can tell you however that I have given Qt applications a chance more than once since 4~5 years, every time with a different version, and every time I ran into internationalization problems. GTK has never given me any trouble. So I would think the newest version of GTK is still ahead of Qt for that. I think it's because it was built to support UTF-8 from the start.
My locale is ja_JP.UTF-8, by the way. Tofu,
I found that Qt 4.5 is very new and no major Linux distro supports it. 4.2, 4.3, or 4.4 are the Qt versions available in the latest versions of the major distributions. Why are you so aggressive to use very new version of Qt, while you are very conservative to stay on the very old version of GTK? Because (for another project) we'll be shipping the viewer with Qt 4.5 on all platforms anyway, so the system version will be irrelevant.
Why you don't bundle GTK while you do Qt? What's the difference?
GTK has an incredibly longer ad-hoc dependancy chain.
Hmm.
Then, how about making use of dynamic load (i.e., dlopen() et. al.) to access to modern GTK functions and/or GtkGLExt functions?
Is this acceptable to LL? That does address the deployment concerns AFAICT - I like it.
I don't know if it will work out well in reality (I'm guessing that GTK is a bit dlopen-hostile like GStreamer is, needing some dirty hacks) but I'm interested in seeing. 
So, one important question I think - do you have a feeling for how ABI-stable GtkGLExt is? (I was pleased to see that it is now maintained again.) GTK itself is fairly ABI-backwards-compatible. For the dlopen'ing of GtkGLExt, GtkGLExt has to be similarly stable or we need to rethink. Gnome settled for GtkGLArea for the GL context, now named GdkGL:
http://bugzilla.gnome.org/show_bug.cgi?id=119189#c54
The support is official for the context, but they still leave the makers of GtkGLArea and what's left of GtkGLExt authors to work together for the higher end functions. The gl context (from gtk) is only what is needed. They provide the source files (gdkgl.c/.h) to get the context. Keyboard input could be routed through an eventbox instead of the default event handler. Gtk already has functions that take care of propagation when rerouted. MainWindow->EventBox->GdkGL Make the EventBox AppPaintable. Use the GL context created by GdkGL to draw into instead of the one now created by llwindow. This way you don't need to worry about the rest of the functions gtkglext provides, and no redesign of the *draw() methods need to be done. You'll just need to redesign the keyboard input routines to queue from Gtk.EventBox instead of SDL. In review of Alissa's patches (20081221, 20081228), it seems apparent there is question of how immodule is affected between grabs & event pumps. Under the implementation now with the embedded browsers, it seems like that question is if, for example, a hotkey would corrupt immodule sequences under pumped events.
Looks like Alissa already commented, in the patch, about the current design. Instead of the EventBox I noted above (which can't force grabs, but the window can), it seems like a possible interim solution is to pass a new GtkWindow(popup) to gecko and use that for the embedded renders, which could either be copied back to the main gl context as the window stays hidden or shown as-is ontop of gl (maybe transient). This solution probably would require more design changes then LL would be willing to handle, I bet. I'm not an expert on immodule to test all options, but this is one way to separate keyboard contexts with built-in features of gtk. The main window can forward events to the subwindow if needed, which is kind-of how the other suggested solutions above work. Right now I have a GTK/GLArea (Gdkgl), which provides the render surface for gl context instead of SDL. Allissa's llkeyboardgtk code is helpful here to glue the rest of the code together. I can't use the design of llwindowgtk since it grabs everything. I have other focus points in my window besides just a single gl area. Hence, my suggestion above. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Use GTK for Linux Viewer input handling, especially unicode input
I agree that GTK's immodule is far better than SDL's. The problem is that immodule API seems heavily depends on implementation details of GTK windowing mechanisms, and it is no trivial to make it run on LLUI components. We could port entire GTK on top of OpenGL surface (GTK can run on bare frame buffer hardware, so it is not impossible to do so, if you don't count the performance.) This approach is a good news for Linux users. However, for Windows and MacOS users, I don't think use of GTK is a fortune, because immodule can't fully support the modern features of Windows and MacOS input methods.
Another approach to improve the Linux users's Japanese input experiences is to drive SCIM directly. SCIM is yet another beast, but it is designed for more platform/environment neutral in mind.
It will be fun to play with it, anyway.