GNOME Bugzilla – Bug 101360
Enhanced Ethiopic IM
Last modified: 2014-08-03 19:09:27 UTC
The Amharic and Tigrigna input methods use ' (apostrophe) as a dead key to end a composition, it maps to GDK_dead_grave. This works perfectly with the tests/testtext application, however everywhere else it seems (such as gedit) a character that appears like a comma appears after ' is struck. I've copied and pasted the char into a file, ran it thru perl and it appears to be 0xfe50. I've included a uuencoded version of the char in a file below. begin 664 fe50 $[[F0"@`` ` end
Well, it's not too unexpected considering the compose tables: '\'', 0, 0, 0, 0, 0, GDK_dead_grave, /* hopefully this has no side effects */ '\'', '\'', 0, 0, 0, 0, GDK_apostrophe, The last column isn't a GDK key symbol, it is a Unicode code point; GDK_dead_grave is a GDK keysymbol that happens to have the value 0xfe50. I see the same behavior in testtext and gedit, and don't see how it could ever work. If you want ' to end a compose sequence, you could: A) Add a variant with ' at the end to all incomplete sequences; for exampleimam-et.c: #define SYL(a,b) \ a, 0, 0, 0, 0, 0, b+5, \ + a, '\'', 0, 0, 0, 0, b+5, \ a, 'A', 0, 0, 0, 0, b+3, \ a, 'E', 0, 0, 0, 0, b+4, \ a, 'I', 0, 0, 0, 0, b+2, \ a, 'O', 0, 0, 0, 0, b+6, \ a, 'U', 0, 0, 0, 0, b+1, \ a, 'a', 0, 0, 0, 0, b+3, \ a, 'e', 0, 0, 0, 0, b, \ + a, 'e', '\'', 0, 0, 0, b \ a, 'e', 'e', 0, 0, 0, b+4, \ a, 'i', 0, 0, 0, 0, b+2, \ a, 'o', 0, 0, 0, 0, b+6, \ a, 'u', 0, 0, 0, 0, b+1, B) Override the filter_key_press() method and implement it explicitely; something like: static gboolean im_am_et_filter_keypress (GtkIMContext *context, GdkEventKey *event) { GtkIMContextSimple *context_simple = GTK_IM_CONTEXT_SIMPLE (context); if (context_simple->tentative_match && event->keyval == GDK_apostrophe && (event->state & gtk_accelerator_get_default_mod_mask() == 0) { gtk_im_context_reset (context); return TRUE; } else return parent_class->filter_keypress (context, event); }
really, really odd that I wasn't seeing the char with testtext at my end, must be a font issue. Anyway, is there a GTK or GDK def for a dead key?
It's not a key, it's a unicode character. While we could say that a 0 in that column means "do nothing", that would require changes to gtkimcontextsimple.c and I don't think it would do what you want anyways.
Created attachment 13203 [details] UUencoded tar of source updates
The sources I've just attached make 3 enhancments to the ethiopic input methods. 1) fix the dead key / apostrophe issue. 2) enhance labiovelar entry to work normally (corrects a visual issue) 3) dynamic numeral system conversion. when ethiopic numbers are composed they are converted between numeral systems before rendering. GTK_MAX_COMPOSE_LEN limits the numeral sequence length that can be input though, I'd like to look in ways to extend this a bit later (can ->compose_buffer be redfined as a pointer and malloced to this default size, and reset as needed?)
Created attachment 13209 [details] ignore last attachment, use this
Created attachment 13284 [details] [review] modules/input/Makefile.in patch for new sources
Created attachment 13737 [details] Newer gez-util.c file, replaces previous.
The gez-util.c file just submitted replaces the version in patch 13209. It has a small adjustment that fixes a problem experienced by some apps (gnome-terminal was one).
Can you provide a patch with only 1) and 2)? I'm not comfortable putting 3) into the stable 2.2.x branch.
> Can you provide a patch with only 1) and 2)? I'm not comfortable > putting 3) into the stable 2.2.x branch. As a last resort yes, but what causes discomfort with 3)? It doesn't have side effects with respect to stability, nor breaks compatibility with anything. I and a few friends have used it for a solid month now without issues.
- It's additional code I would have to review, and probably would take a few passes back and forth to agree on. I'm trying to get 2.2.1 out in the next day or two. So, unless we can separate the fixes from new code, the fixes probably aren't going to make 2.2.1. - The ->compose_buffer issue needs some consideration. - In general new features simply aren't supposed to go into the stable series.
Created attachment 13891 [details] [review] patch for issues (1) and (2) only
Patch 13891 is the quickest possible patch I could do to correct the first two issues (based on a development stage before the issue 3 work was done). Issue (2) still required a fair amount of new code, hope that's ok. Please do get the numeral support patch into the development branch at the next opportunity (if another month goes by I'll forget how it works :)
Comments: - Any code in GTK+ has to follow the GTK+ and GNU coding standards; see pango/docs/TEXT/coding-style for an overview and pointers. - Having this much code duplicated from GtkIMContextSimple is rather ugly. Having all the code duplicated from GtkIMContextSimple in all three ethiopic input methods is really not good at all. What you might want to consider is: - Put all three ethiopic into a single module (there is no requirement that each module has exactly one input method) - Create a GtkIMContextEthiopic that has the code customizations you need - Derive the other input methods from this - I really don't want to put this much new code in for 2.2.x ... I didn't realize that the labiovelar stuff wasn't just an adjustment to the tables. One possibility if you don't want to be tied to the GTK+ development schedule is that I could just remove the ethiopic input methods from the GTK+ distribution and you could distribute them separately.
Created attachment 13961 [details] Apostrophe fix only (tar ball)
The tar just attached fixes the apostrophe problem only. It takes code sharing as far as I can take it. Shared code is back in the "gez-util.c", in essence it is a stripped down version of earlier submissions. The Makefile.in in attachment 13284 [details] [review] will build the sources. I *believe* the code style is in accordance with the pango reference. > - Create a GtkIMContextEthiopic that has the code customizations > you need > - Derive the other input methods from this I would like to take this approach to get the labiovelar and numeral enhancements into gtk+-2.4. GtkIMContextEthiopic I assume would have to derive from GtkIMContext or GtkIMContextSimple? The GTK class and inheritence model is still fuzzy to me, any pointers for where to start? If I can get over that hump...I'd be happy to lend my hands to GTK development in other areas. > if you don't want to be tied to the GTK+ development > schedule is that I could just remove the ethiopic > input methods from the GTK+ distribution and you could > distribute them separately. This outcome I'd like to avoid at all costs. I'm fine with following the GTK+ development schedules, I'll just have to pay attention to what they are, that's easy enough :-)
The coding style is pretty close to right. Some things I see: static gboolean gtk_im_et_context_simple_filter_keypress ( GtkIMContext *context, GdkEventKey *key); Don't break the line there; the parameters need to be aligned in columns. gtk_im_et_class_init ( GtkIMContextClass * im_context_class ) Should be: gtk_im_et_class_init (GtkIMContextClass *im_context_class) if (context_simple->tentative_match && (event->keyval == GDK_apostrophe) && (context_simple->tentative_match_len == 1) && ((event->state & gtk_accelerator_get_default_mod_mask()) == 0)) Should be: if (context_simple->tentative_match && event->keyval == GDK_apostrophe && context_simple->tentative_match_len == 1 && (event->state & gtk_accelerator_get_default_mod_mask()) == 0) [Mostly, move the && to the previous line, though I tend to not use extraneous parentheses in this situatin ] return (parent_filter_keypress(context, event)); Should be: return parent_filter_keypress(context, event); 'return' is not a function. In terms of general approach, I dislike putting the class_init functions and method implementations into gez-util.c. We try to keep each object implementation one file. What I would do is have a: gboolean im_et_check_for_apostrophe (GtkIMContext *context, GdkEventKey *event); function in gez-util.[ch], and have the three methods, do, in there filter_keypress() method: if (im_et_check_for_apostrophe (context, event)) return TRUE; else return parent_class->filter_keypress (context, event); See gtkimcontextim.c for how to set up a parent_class variable. The basic idea is that while we have a lot of flexibility in how we do things with the GObject object system, we want to keep things standardized. And splitting up a single class between multiple files is definitely non-standard.
Created attachment 13990 [details] updated tar ball for apostrophe fix
The last patch (13990) should be in step with what was requested, or I've misunderstood. I will follow gtkimcontextxim.c as a guide for developing a GtkIMContextEthiopic for 2.4, thanks. BTW, the parent_class assignment in gtkimcontextxim.c is never used! It might be dead code, fortunately it is still useful for guidance :) In this patch, return parent_class->filter_keypress (context, event); would not work, since filter_keypress was not a member of the class, I've used a function pointer to filter_keypress that is assigned during class init. > Should be: > if (context_simple->tentative_match && > event->keyval == GDK_apostrophe && > context_simple->tentative_match_len == 1 && > (event->state & gtk_accelerator_get_default_mod_mask()) == 0) I must say this gave me pause, is it not a reversal of the GNU coding standard? http://www.gnu.org/prep/standards_23.html#SEC23
Created attachment 15275 [details] [review] Tarball of new Ethiopic IM sources
Created attachment 15276 [details] [review] UUencoded tarball of new Ethiopic IM sources
Created attachment 15277 [details] This is the right patch... (ignore last two)
The patch with id=15277 provides GtkIMContextEthiopic which fixes the original bug in this bug report, enhances labiovelar entry, and offers ethiopic numeral input with inline coversion up to 10^25. The new sources no longer dependend on GtkIMContextSimple but borrows a fair number of the private functions from gtkimcontextsimple.c. Perhaps this can be enhanced later. There is one defect that I hope a more experienced person here can remedey. When changing from the Amharic (or Tigrigna) to default and then back, there error message appears: GLib-GObject-WARNING **: cannot register existing type `GtkIMContextEthiopic' I don't know the mechanics of module registration and haven't found where this occurs.
Created attachment 15311 [details] Source with circular IM sequences.
Attachment 15311 [details] adds support for circular sequences. The Ethiopic IMs are now in want for nothing and I have no remaining features to add.
Created attachment 16315 [details] module reregistration bug fix
The last attachment (16315) is a c source file replacement for the version found in attachment 15311 [details]. The bug is actually in glib, but a finalization issue is also addressed in the new source. Along the way I noticed that the parent_class pointer in gtkimcontextxim.c is dead code.
Created attachment 16364 [details] Updated Makefiles to build libgtkimcontextethio.so
Attachment 16364 [details] builds gtkimcontextethio.c into a shared library that is linked against the 3 IMs that depend on it.
Created attachment 21445 [details] Sources for New Ethiopic IM Under gtk+2.3.0 (Makefile.am, Makefile.in updates)
Have you considered moving your new module to http://gtk-im-extra.sourceforge.net/ ?
Moving off the 2.4.0 milestone
Created attachment 26760 [details] IM source update for GTK+ 2.4 This gzipped tar contains the sources of the enhanced ethiopic IMs for the GTK+ 2.4.x series. The enhanced sources are unchanged from 2.3, the difference is in the Makefile.am and Makefile.in which builds the sources differently. Specifically it does *not* make the libgtkimcontextethio.so shared library which had memory problems, rather it compiles gtkimcontextethio.c into the individual im modules. So the im modules are slightly fatter but no segfaults on reloads, go figure. The sources work out of the box and make the world a better place, please include with next gtk+ release.
Daniel, any updates?
Created attachment 113241 [details] Incremental Update for 2008/06/22 Attaching a tarball of a near-final update that resyncs with latest GTK+ and Unicode 4.1 Ethiopic extensions. Very many improvements as discussed offline. Essentially bugzilla is being used here in a CVS/backup capacity. The final update should come by mid July (waiting recommended), see the README.txt for more.
Created attachment 114369 [details] Incremental Update for 2008/07/10 Again using the bug report to archive significant updates. Still on target to finish mid-July.
closing out old bugs. We nowadays prefer input methods to be integrated in the platforms im framework of choice, in the gnome case: ibus