It is currently impossible to have a simple XKB keyboard layout that is simple yet flexible enough to allow to print composed characters on one keystroke or with the help of deadkeys. I'm dealing with languages requiring tone marking, this means they need basic accents. That's fine for a,o,u,i,e, they can be accented with dead_key or one keystroke. But as soon as I need the open o U+254 and the open e U+25C, I am force to have a different behaviour, i.e. I must composed the base with accent with two keystrokes. Could it be possible to have something like "press A0" -> "print U+254 and U+301" ? I know I could use advanced IME, but this is more than what I need. Microsoft Keyboard Layout Creator allows to have one-to-many keystroke to characters. Having flexible deadkeys capable of printing many characters instead of only precomposed one would be nice too.
from comments to bug 2693. I'm thinking we could maybe have additions to the list of named characters (keysyms?) like Aacute, Cyrillic_ka and the likes. Unicode has http://www.unicode.org/Public/UNIDATA/NamedSequences.txt which is sort of incomplete, it doesn't contain all the characters I'm dealing with for Lingala for example and there is not process to add to it. So the best option is for us to have such a list, add to it over time, and allow xkb to use it in layout definitions. Another way is through a Compose file with some kind of locale stuff. http://malayalamlinux.sourceforge.net/input-methods/ is doing that for "ണ്", "ന്", etc. Unfortunately it seems to be local specific.
i'll take this one
-
*** Bug 1460 has been marked as a duplicate of this bug. ***
Is there any updates about this issue?
nope, unfortunately i've had a ton of other input stuff to do. it's still on the todo list, and i'll post to the bug when i've looked at it, but it won't be for a little while yet.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Daniel, you seems too busy. Can more xorg developers be assigned to help?
Xorg developers are volunteers - they don't get assigned, they get asked nicely if they have some spare time.
(In reply to comment #9) > Xorg developers are volunteers - they don't get assigned, they get asked > nicely if they have some spare time. > Sure, that's what I meant. Sorry if the wording was misunderstood and appeared not nice. I hope that more volunteers can help with this enhancement.
I might be missing something. I think you can already have the option to press a single key (or sequence) and produce two characters (maybe more). Could you try 1. Create a file ~/.XCompose 2. Add <asterisk> : "#+" 3. Run GTK_IM_MODULE=xim gedit 4. Press * You should get '#+'. Is that what you are trying to achieve? GTK+ IM has the potential to handle these as well.
On Fri, Sep 05, 2008 at 04:18:14AM -0700, bugzilla-daemon@freedesktop.org wrote: > I think you can already have the option to press a single key (or sequence) and > produce two characters (maybe more). > > Could you try > > 1. Create a file ~/.XCompose > 2. Add > <asterisk> : "#+" > 3. Run > > GTK_IM_MODULE=xim gedit > > 4. Press * > > You should get '#+'. > Is that what you are trying to achieve? > > GTK+ IM has the potential to handle these as well. Sure, but doing it IM-side eliminates the potential to have this working properly in multiple layouts where the engravings require two keysyms.
Created attachment 18699 [details] A .XCompose file (put in your home directory) I attach a sample .XCompose, with the compose sequences, <Multi_key> <minus> <minus> : "$" dollar <asterisk> : "#+" <dead_acute> <t> : "t́" The third sequence, if you have a layout active that allows to type dead_acute, allows you to press dead_acute + t, and you get t́. Obviously, there is no precomposed t with acute in Unicode yet, and this is actually two characters ('t' + 0x301) that are printed.
(In reply to comment #12) > On Fri, Sep 05, 2008 at 04:18:14AM -0700, bugzilla-daemon@freedesktop.org > wrote: > > I think you can already have the option to press a single key (or sequence) and > > produce two characters (maybe more). > > > > Could you try > > > > 1. Create a file ~/.XCompose > > 2. Add > > <asterisk> : "#+" > > 3. Run > > > > GTK_IM_MODULE=xim gedit > > > > 4. Press * > > > > You should get '#+'. > > Is that what you are trying to achieve? > > > > GTK+ IM has the potential to handle these as well. > > Sure, but doing it IM-side eliminates the potential to have this working > properly in multiple layouts where the engravings require two keysyms. > I have read this a few times; I might be doing something wrong, but I do not have experience with the case you are describing. If you can give more information (example), I would really appreciate it.
Fixed in xkbcommon, which has new syntax like: key <HELO> { [ h, i, { h, e, l, l, o }, { H, E, L, L, O } ] }; to produce 'h' from level 1, 'i' from level 2, 'hello' from level 3, and 'HELLO' from level 4.
(In reply to comment #15) > Fixed in xkbcommon, which has new syntax like: > key <HELO> { [ h, i, { h, e, l, l, o }, { H, E, L, L, O } ] }; > > to produce 'h' from level 1, 'i' from level 2, 'hello' from level 3, and > 'HELLO' from level 4. Great! So, should we submit patches now to layout definitions to use this new syntax instead of old hacks?
Heh, the problem is that it's not yet supported in X11 ... :) Getting it supported in X11 will take a new protocol (XKB2, although this is a lot more simple than previously thought), as well as getting toolkits to migrate to libxkbcommon rather than using the libX11 XKB APIs, which don't support this in any way. So, er, sadly it's a little way off. But at least part of the infrastructure is there!
I see, big step forward nevertheless.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.