GNOME Bugzilla – Bug 567443
Updated keysym definitions, compose table
Last modified: 2018-02-10 03:40:35 UTC
With this set of patches 1. we update the gdk/gdkkeysyms.h file with upstream (several dead keys added, etc) 2. we use 32-bit values for keysyms in gdk/gdkkeysyms.h (braille, some latin extended, some cyrillic, arabic, farsi and misc) 3. we update the gdkkeysyms-update.pl and compose-parse.py conversion scripts 4. we update gtkimcontextsimpleseqs.h with upstream 5. we update gtkimcontextsimple.c, support 32-bit keysyms, add new dead keys in check_algorithmically().
Created attachment 126241 [details] [review] Updated gdk/gdkkeysyms.h
Created attachment 126242 [details] [review] Updated gdk/gdkkeysyms-update.pl
Created attachment 126244 [details] [review] Updated gtk/compose-parse.py Copy also available at http://github.com/simos/compose-parse/
Created attachment 126245 [details] [review] Updated gtk/gtkimcontextsimpleseqs.h
Created attachment 126246 [details] [review] Updated gtk/gtkimcontextsimple.h Allows to use 32-bit keysyms. check_algorithmically() now knows the new dead keys that were added recently. Uses about 30KB more memory in gtk+ library.
Hmm, seems a bit unfortunate to blow up the table size by a factor of 2, if there is not even any 32bit keysym in any sequence.
I wonder, wouldn't it be reasonable to surround the workaround for a bug in X in gtkimcontextsimple.c with #ifdef GDK_WINDOWING_X11? Windows hardly has the same bug. On the other hand, I have some Windows-only patches in the works that will make behaviour match "native" behaviour and user expectation better for some dead key sequences on that platform. Like the one attached below. Do you think this is a reasonable way to fix the problem described in the comment?
Created attachment 127433 [details] [review] Suggested patch
(In reply to comment #8) > Created an attachment (id=127433) [edit] > Suggested patch > Ideally, the way this could be solved would be to create a custom compose table with the compose sequences you want, which would override the X.Org compose sequences.
Hmm, like having an optional platform-dependent compose table in the same format as gtk-compose-lookaside.txt that one would pass through the compose-parse.py script which would then output the platform-dependent table source file? Sounds good, but I guess that requires some small change to that script. Also, some Win32 special casing is ideally dependent on which keyboard layout is in use: see bug #569581. So just a table-based approach is not sufficient, some code is also needed.
Actaully, all cases I know of where the user expectation on Win32 is different from that based on the X tables is dependent on keyboard layout... So just using one fixed Win32-specific additional table is not enough. And as the special cases are pretty trivial to code explicitly, I think I will continue to do that. What evetually could be done, I guess, is to do some even hairier investigation of the keyboard layout's mechanism in gdkkeys-win32.c:update_keymap() (which is called once initially, and whenever the keyboard layout is changed) so that it would generate a table of the form that gtkimcontextsimple expects. Hmm.
(In reply to comment #10) > Hmm, like having an optional platform-dependent compose table in the same > format as gtk-compose-lookaside.txt that one would pass through the > compose-parse.py script which would then output the platform-dependent table > source file? Sounds good, but I guess that requires some small change to that > script. compose-parse.py mixes the sequences from gtk-compose-lookaside.txt into the X.Org compose sequences. I could add an option to the script so that it processes a custom input file and produces a single platform-dependent table source file. Alternatively, you could maintain the file directly in the final C source form. Then, in check_win32_special_cases(), you could add at the start + if (check_table (context_simple, gtk_compose_table_win32->data, n_compose)) + return TRUE; so that you can catch those cases that require to override the standard compose sequences.
(In reply to comment #12) > (In reply to comment #10) > > Hmm, like having an optional platform-dependent compose table in the same > > format as gtk-compose-lookaside.txt that one would pass through the > > compose-parse.py script which would then output the platform-dependent table > > source file? Sounds good, but I guess that requires some small change to that > > script. > > compose-parse.py mixes the sequences from gtk-compose-lookaside.txt into the > X.Org compose sequences. I could add an option to the script so that it > processes a custom input file and produces a single platform-dependent table > source file. > Alternatively, you could maintain the file directly in the final C source form. > > Then, in check_win32_special_cases(), you could add at the start > > + if (check_table (context_simple, gtk_compose_table_win32->data, n_compose)) > + return TRUE; > > so that you can catch those cases that require to override the standard compose > sequences. > If you opt to use a standard format file for these win32 compose sequences, I updated compose-parse.py (http://github.com/simos/compose-parse/) so that 1. The script now supports the option "--win32". 2. Requires to have a local file named "gtk-win32-sequences.txt" with content of the form <dead_acute> <space> : "'" <dead_grave> <space> : "^" <dead_acute> <a> : "á" <Multi_key> <a> <e> : "æ" <Multi_key> <A> <E> : "Æ" <Multi_key> <a> <e> : "æ" 3. You run the script with ./compose-parse.py --win32 and it produces the table for inclusion in gtk+. It also performs some sanity checks on the input.
Any updats on this? this issue causes a big usability problem for Arabic users.
Hello Simos, Could you take a look to bug #601234 ? Maybe you can fix it with an updated gtk/gtkimcontextsimpleseqs.h file.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.